Allow the same state name in different parallel machines

[karl]

When creating parallel machines, every state must have a unique name.

For example:

parallel {
    bold{
        first.on -> first.off;
        first.off -> first.on;
    },
    underline{
        second.on -> second.off;
        second.off -> second.on;
    };
};

I'd like to be able to have the states just be named on and off.

Expected Behavior/Possible Solution

I wonder if when using the json representation of the state machine we could have the idea of states having something like a displayName that when provided is used for rendering the state name.

This would allow me to use the current name field as a unique id, with displayName giving a nice compact output.

Context

I'm working on a library to convert xstate state chart descriptions in svg diagrams using state-machine-cat.

With xstate you can re-use the same state name across each part of a parallel or nested state machine. I'd like to be able to preserve these state names in the diagram output from state-machine-cat.

[sverweij]

@karl Thanks for interest in state-machine-cat, and for raising this issue. It'll probably make state-machine-cat a little better...

I think your possible suggestion is the way to go; separating name and displayName (or id and label) is sound software engineering. It'll get the drag out of typing really long names lots of times as well. I designed that into msgenny from the start, but for state-machine-cat I didn't. Lazy, I guess :-) Also the msgenny approach (label behind dots) wouldn't work in state-machine-cate because the dots are already in use to separate the state's name from its activities.

Aside: scoping state names ("id's") - so they'd have to be unique within their own containing state only - is worth considering as well. I'll have a peek at what the scxml (and/ or xstate) folks did there.

Implementation wise I would propose to slap the displayName (label) in a square brackets construct, just before the :. That enables us to later expand it with other attributes (e.g. colors might make some folks happy):

unset [label="alarm not set"],
set [label="alarm set"]: show a bell;

unset => set: time entered;

The json would then look something like this:

{
    "states": [{
        "name": "unset",
        "label": "alarm not set",
        "type": "regular"
    }, {
        "name": "set",
        "label": "alarm set",
        "type": "regular",
        "activities": "show a bell"
    }],
    "transitions": [{
        "from": "unset",
        "to": "set",
        "label": "enter time",
        "event": "enter time"
    }]
}

In scjson/ scxml we can put the label into the name attribute that the scxml designers made for this. And pray we can put any string in there we want (unlike e.g. the id and event attributes ...)

...
<state id="unset" name="alarm not set">
    <transition event="enter_time" target="set"/>
</state>
...

[karl]

That all sounds great!

Let me know if there is anything I can do to help out with this.

[sverweij]

@karl thanks for the offer! If you could give the new version a try and supply feedback (like you did with #15) that'd be massively helpful.

Version 2.7.0-beta-1 is now on npm (with the beta tag) that has

• the ability to give states display names (with a 'label' attribute)
• a dot (and hence svg) reporter that output display name instead of the name if it's there.
• (an smcat reporter that reproduces the input, formatted, including any labels)

Also: I've checked the scxml spec

• they don't have separation between id and name as I initially understood - so the scxml/ scjson renderers stay untouched).
• they don't scope id's to nested states - "In a conformant SCXML document, the values of all attributes of type "id" must be unique within the session. (...)" w3 scxml spec, IDs section - emphasis mine.

[karl]

I'm very happy to test this and supply feedback. I should have time to look at it tomorrow.

Thanks for the quick turnaround on this!

[karl]

Just had a chance to have a quick play around and this looks great!

[sverweij]

Thanks @karl both for requesting this feature and for trying the beta

The PR is merged and released a new major version of state-machine-cat. No worries; the version bump is major because I had to make a small breaking change in the syntax to introduce the label attribute - see the release notes for details).