Semantic meaning of state.value

[dimsuz]

Hi!

I'm trying to understand the semantic meaning of state.value. I can see that it is used to navigate/inspect state machine transitions in some cases. Questions:

• I see that it is based purely on schema keys, not state IDs. Why? Couldn't state id (or a set of state ids in parallel case) be used to identify the current machine state?
• In what other cases state.value can be useful other than pre-configuring or inspecting a machine state?

I am generally curious to understand what state.value is on a semantic level and is the schema-key based representation is the only good one. Also SCXML doesn't seem to mention such entity, so I think it was invented by xstate.js for some practical purpuses?

[davidkpiano]

I see that it is based purely on schema keys, not state IDs. Why?

Because keys identify the hierarchical path to a state node. This is the difference between representing a state like this:

{
  active: {
    brightness: 'bright',
    mode: 'light'
  }
}

Rather than this:

[
  'active',
  'active.brightness',
  'active.brightness.bright',
  'active.mode',
  'active.mode.light'
]

Or with some unique IDs:

// examples of IDs
[
  'active',
  'brightness',
  'bright',
  'mode',
  'lightMode'
]

It's more concise and useful to represent a state value (which represents the finite state) as its hierarchical representation, rather than just as a collection of IDs.

Couldn't state id (or a set of state ids in parallel case) be used to identify the current machine state?

They can, but it's not as useful for the reason above. When you have an object (hierarchical representation), not only do you represent all of the state nodes in a compact manner, but you also represent their paths in the statechart. This is important for visualizing state nodes.

In what other cases state.value can be useful other than pre-configuring or inspecting a machine state?

It's useful in state.matches(...) because instead of checking individual states:

// pseudocode
state.matches('#active') && state.matches('#lightMode')

You can use the natural hierarchical representation:

state.matches({ active: { mode: 'light' } });

I am generally curious to understand what state.value is on a semantic level and is the schema-key based representation is the only good one.

For XState, state.value represents the active state nodes of the given state, which represents the finite state of the machine (not the extended state). I'm not sure if it's the only good one, but I'm convinced that it is the best one for XState's use-cases.

Also SCXML doesn't seem to mention such entity, so I think it was invented by xstate.js for some practical purpuses?

It is an XState "invention", and you're right, it's for practical purposes.

The equivalent in SCXML is the internal configuration variable, which is a set of active state nodes. The reason I used an object syntax is that it has more compact serialization. Also, if you were to use IDs instead of the key-based representation, it's very possible to have conflicts, since nothing is stopping you from making two <state> elements with the same id. This is naturally impossible with JSON:

{
  "foo": {
    "bar": "baz",
    "bar": "quo" // can never happen!
  }
}

Similarly, by joining the path to each state node via its keys as its "default" ID (e.g., "active.mode.light", which represents the path ['active', 'mode', 'light'] to that state node), you naturally have a unique ID. There will never be any conflicts. And it greatly simplifies the "naming things" problem.

Hope that helps!

[dimsuz]

Thank you David! As always your answer is very detailed and informative, I have all the answers I asked for!