Parallel state machine

[teux]

Hi there.
My compound SM has two states - loading and complete. In turn, the loading is a parallel state that has multiple children for loading some pieces of application data. It's a sort of this:

The state machine itself is a stateNode. I have marked it as 'parallel' and then I've removed redundant loading and complete states:

createMachine({
  id: 'dataFeedMachine',
  type: 'parallel',
  data: ctx => ctx,
  states: {
    claim: {/** ... */},
    organiztion: {/** ... */},
    jsonSchema: {/** ... */},
  }
})

The machine works as I expect. It has finished when all parallel states had finished.

I was hoping the machine will send it's context in done event: data: ctx => ctx
But it doesn't. Done event contains empty data key and of course data callback has not been invoked.

Will be great if a parallel state node can process its own data callback

[davidkpiano]

Great diagrams! Can you make a reproducible CodeSandbox example for this?

[teux]

Hi David,
Please see this sandbox

I've made parallelStateMachine and parallelMachine.
The first one contains parallel state loading and final state complete.
The second one is parallel by itself (has top-level type: 'parallel').

Each of them invokes three fetchMachine and stores its results in the context. Then they fire done events.
The auxiliary appMachine serves to invoke those two machines and log the done events.

[davidkpiano]

So this is one of the awkward parts about SCXML: you can only specify "done data" (the data property) on <final> states. However, you're doing the right thing by assigning that data to context for use later. If you modify your machine to have a final state, it works as expected:

export default createMachine<Context>(
  {
    id: "parallelMachine",
    context: {
      results: []
    },
    initial: "tasks",
    states: {
      tasks: {
        type: "parallel",
        states: {
          ...parallelStates
        },
        onDone: {
          target: "success"
        }
      },
      success: {
        type: "final",
        data: (ctx) => ctx.results // << this works!
      }
    }
  },
  { ...machineOptions }
);

[teux]

Oh, I got it. I'v read the SCXML spec a bit and I saw that
donedata can be only on a final state.

In the same time, the procedure isInFinalState(s) defines parallel states as final

elif isParallelState(s):
        return getChildStates(s).every(isInFinalState)

And the procedure exitInterpreter() defines that final state has to return state.donedata:

if isFinalState(s) and isScxmlElement(s.parent):   
            returnDoneEvent(s.donedata)

I agree that there is inconsistency in the spec.
But I'm impressed that xState follows the specs so scrupulously 🥇

[Andarist]

As to the SCXML - I was thinking about this yesterday. I think that donedata is not allowed in parallel states because it's harder for the author of the document to know all possible events that could be received. It's potentially timing-dependent. All paths/events are still known beforehand and the modeling tool would be able to just hint that to the author but it complicates the mental model a little bit. So maybe that's why this is not supported but also, keep in mind, that's just my wild guess.