Nested/hierarchical States

Nested states are beneficial for a myriad of reasons, including:

• State nesting lets you define a new state rapidly in terms of an old one by reusing the behavior from the parent state
• State nesting lets you get new behavior almost for free, reusing most of what is common from the parent states

Configuration

This is what a nested state machine configuration would look like:

// Traffic Lights
useStateMachine()({
  initial: "green",
  states: {
    green: {
      on: {
        TIMER: "yellow",
      },
    },
    yellow: {
      on: {
        TIMER: "red",
      },
    },
    red: {
      on: {
        TIMER: "green",
      },
      // Nested state: Pedestrian traffic light
      initial: "walk",
      states: {
        walk: {
          on: {
            PED_COUNTDOWN: "wait",
          },
        },
        wait: {
          on: {
            PED_COUNTDOWN: "stop",
          },
        },
        stop: {},
      },
    },
  },
});

State value representation:

The returned machine state would still have a string representation for the state value. Nested stated will be represented with dot syntax. For the above example, possible states are:

• green
• yellow
• red.walk
• red.wait
• red.stop

Transitions & Effects

For every transition, the state machine should traverse the config three (depth-first) and find the shortest path for the transition. Effects should be invoked on parent state only once: transitioning between child states should not re-fire parent effects.

[devanshj]

My pleasure!

You can continue with the implementation if you want, as said the implementation types need not be fully type safe. I’ll start working on the user facing types too once I’m done with types for 1.0

[threehams]

Turns out we’re not using nested states at all - we’re invoking other machines and waiting on the results. I think that’s already possible without any changes (thanks, React!) but maybe I’ll propose something if I run into problems.