Visualization API makes overly restrictive assumptions about names

[smartcaveman]

Stateless claims "Generic support for states and triggers of any .NET type (numbers, strings, enums, etc.)". The visualization API is inconsistent with this claim due to overly restrictive assumptions about the names of states and triggers.

The visualization API only supports the minority of .NET types with a value-based implementation/override of ToString(). This is because StateGraph infers the names for states and triggers from the ToString() return value.

This means that:

1. If the ToString() value of the state or trigger is not valid DOT, then the visualization API will produce invalid DOT. I ran into this problem when implementing a generic product state machine operation with the output machine's state represented as a tuple of states for the component machines.

2. If the ToString() value of two distinct states or triggers is the same, the visualization API will fail. It should be noted that this is the default for non-primitive .NET types. (I ran into this problem when trying to use F# discriminated unions instead of enums).

I'm happy to help fix this issue.

I think the simplest solution would be something in the spirit of:

public static class StringRepresentation<TStateOrTrigger> { 
    public static Func<TStateOrTrigger, string> Format { get; set; } = _ => _.ToString(); 
}

(Obviously, ToString() calls within StateGraph would be refactored to call StringRepresentation.Format instead of the ToString method of the state or trigger instance).

[smartcaveman]

@HenningNT @nblumhardt

[nblumhardt]

Hi @smartcaveman -

On 1., I think the answer here is to escape whatever value is produced by ToString() so that valid DOT is produced.

On 2., overriding ToString() is the current recommendation, but extending the formatting methods might be a worthwhile design to investigate.

I'd proritize fixing 1. first, though, as it's clearly a bug WRT the current design.

CC'ing @JeremyCade

[mclift]

On 1., this has been resolved by PR #597, which is included in the current release.

On 2., this remains unresolved but we have a workaround in overriding ToString() that should cover the majority of cases. Is it worth keeping this issue open? If yes, we should discuss an approach; this could be as simple as throwing an exception if ambiguous labels are detected.