Xstate: Question on extracting state machine by key

[ShMcK]

Feature/Question

Feel no pressure to respond to these ramblings :)

I've been considering making a large statechart that governs an entire project. This would provide an overall map of the project for developing/debugging purposes, and ensure everything works together.

I had the idea of targeting smaller chunks of the state for components, providing the component a state scoped and governed by a given xState "key". I assumed this was how "channel"s work in React-Automata, but that doesn't seem to be the case.

Best practices seem to suggest that developers should avoid passing the actual named state into components, as it couples the component to the state machine. I don't see a problem with passing state around as a prop.

Am I way off the mark of how xState should work with components?

• Is it more recommended to have many small disconnected states, or a single large state?
• Is there any easy way to access a nested state machine using a given key? Something like a getStateMachineByKey('someKey')?
• Are there any recommended alternatives to "react-automata" to explore?

[davidkpiano]

If you think about how things work in real life (e.g., electronics) it's a bunch of isolated systems communicating with each other.

With that said, statecharts can also communicate with each other. One way this can be exhibited is by having components with internal statecharts _send_ their state (similar to how dispatch works in Redux, but send is the official term).

For example, in React, this can look like:

<Toggle
  onChange={value => this.handleToggleChange(value)}
/>

Where <Toggle /> might have an internal statechart that looks like:

const toggleMachine = Machine({
  initial: 'active',
  states: {
    active: { on: { TOGGLE: 'inactive' } },
    inactive: { on: { TOGGLE: 'active' } }
  }
});

// ...
// send method on component
send(event) {
  const nextState = // get next state from toggleMachine.transition(...)

  // send the next state
  this.props.onChange(nextState.value);
}

This will send 'active' or 'inactive' to the listener (if you really want, you can map these to true or false but this doesn't scale if you have more than 2 possible toggle values).

You might be thinking, "well this looks like how I've already been doing things in React" and you'd be absolutely correct 😉 It's essentially the same thing, except explicitly modeled.

[ShMcK]

If you think about how things work in real life (e.g., electronics) it's a bunch of isolated systems communicating with each other.

This makes a world of sense.

You might be thinking, "well this looks like how I've already been doing things in React" and you'd be absolutely correct 😉 It's essentially the same thing, except explicitly modeled.

In this case, it's probably simpler to just rely on setState unless the state is shared or has a complicated work flow.

Thanks :)