[Feature Request] Inherit actions from parent state, or global actions

[lins05]

Hi, I'm introduced to this amazing library recently, and I immediately started to see the great benefit of it in one of my projects, thanks very much!

Yesterday I find it impossible to declare something like In this state machine, trigger action A1 whenever event E1 happens, regardless of what the current state is.

In other words, instead of something like this:

const machine = Machine({
  states: {
    s1: {E1: {target: s2, actions: A1},
    s2: {E1: {target: s3, actions: A1},
    s3: {E1: {target: s4, actions: A1},
  }
});

My goal is to replace it with something like:

const machine = Machine({
  globalActions: {E1: A1},
  states: {
    s1: {E1: s2},
    s2: {E1: s3},
    s3: {E1: s4},
  }
});

I tried to implement this as an onTransition listener, however it doesn't work in my case because:

1. my action, A1, sets a value in the context (a timestamp)
2. one of the states, say s2, has a delayed transition, where the amount of delay depends on that timestamp.

E.g. this doesn't work:

const machine = Machine({
  states: {
    s1: {E1: {target: s2, actions: A1},
    s2: {after: [{
            delay: {timestamp} => calculateDelay(timestamp), 
            target: s3
            }]
    },
    s3: {E1: {target: s1, actions: A1},
  }
}, {
  actions: {
    A1: assigner({timestamp: context => updateTimestamp(context)})
  }
});

Because the onTransition listeners only happens after transitioning to the new state, calculation of the delay is already done when the listener is called. Even the pattern interpret(machine, {execute: false} and manually call service.execute(state) doesn't help here.

So my question is: am I missing something that could be used to achieve this globalActions pattern, or it's not supported by xstate yet? If the latter, does it make sense to add support for it?

[davidkpiano]

It's not supported in XState because it's not supported in SCXML. There is an idea explored by Harel in his original paper called "clustering" which addresses this, but that idea was scrapped because of its complexity/ambiguity.

Anyway, there's a couple of ways to solve this. You can be more explicit and have two types of events; for example:

• E1 can be for executing A1
• E11 can be for transitioning between states

So if you think of the logic in plain terms, you can phrase it this way:

Whenever E1 happens, execute A1 and trigger a transition between the states

That second part can be the responsibility of that E11 event. A machine can send itself events, so:

const A1 = () => console.log('Action A1');

const machine = Machine({
  initial: 's1',
  states: {
    h: { type: 'history' },
    s1: {on: {E11: 's2'}},
    s2: {on: {E11: 's3'}},
    s3: {on: {E11: 's4'}},
    s4: {/* ... */}
  },
  on: {
    E1: {
      target: 'h',
      actions: [A1, send('E11')]
    }
  }
});

See the visualization here

A machine sending itself events is a powerful technique, and it's how most embedded electronics work (which use state machines/statecharts extensively!).

[davidkpiano]

Please note the edited machine above. I added the history state h because the transition is on the machine, which means that the child states will be exited and will otherwise reenter at s1 every time.

[Andarist]

@davidkpiano this is a very interesting example - wouldn't have thought about using history state like this. Would be great to have such a recipe in the docs 📚

[lins05]

This definitely a genius & elegant idea, thanks for the swift help @davidkpiano !