:wave: XState noob here. Need some help understanding parallel states.

[cedar kelp]

Hi all,

I need to understand how to create parallel states in the Editor, specifically these two permutations:

• N parallel states, ALL of which need to complete before moving on, with an onDone and onError next step
• N parallel states, only a specific one that needs to complete before moving on, the others should not block the machine from progressing to the next state

I think I can sort it out with code, but I need to understand how to do it with the editor (and see if it's easy enough for biz people to follow) before committing to xState as the lib to use 🙂

[raw stag]

Creating N states in Studio is O(n) time spent creating states in Studio afaik but you could easily automate creating base cases into code you can import into Studio

For 1) When a parallel state reaches it's final you just need to check the other parallel states for their final state and only transition when that guard passes, for 2) you can just transition normally. So 1) will be much more time-consuming to setup than 2) will be

[cedar kelp]

I see, thank you!

If I could tack in one more question, entering new states should trigger an action (send a pubsub message), I also store the JSON config of the machine in DB (this is supposed to be created with a UI, either Studio or failing that a home grown one), how can I restore the machine and actor considering these actions could be dynamic based on the config?

[raw stag]

If you need an actor to start in a certain state, you can use a combination of input and guards to have that happen

You can also play around with snapshots but I prefer to make that behaviour part of the machine in question

[cedar kelp]

Is there some example I could look at?

I have only experimented with snapshots

(also cause they can be persisted/serialized, seemed like an obvious choice)

[raw stag]

I don't have one to hand but for my preferred method you add an initial state with its transitions guarded by something in the input of the machine

For snapshots, checking the docs or searching this server would be better info than I can give you :D

[cedar kelp]

Gotcha, I think I have a rough version down, at least using snapshots 🙂 Will dig deeper into the docs to see if I can get some clarity on your preferred approach. What are the tradeoffs between the two?

[raw stag]

With an initial state, the decision of which state to enter is encapsulated in the machine itself

With snapshots, you're managing those outside of the actor in question

[cedar kelp]

right, but I guess in that sense you can't serialise without snapshots, or am I wrong?

btw this is all backend based, trying to build a relatively complex async flow

[raw stag]

It's -end agnostic

[raw stag]

All serialization is is taking data out of the machine and putting it in a persistable format, you can use the functions Xstate provides for that, or you can just use an emit action or something that spits out only what you need to persist

[cedar kelp]

I get that, but I also mean that this would have to work with pods restartings between events, or even a machine having to be resumed on a different box

[raw stag]

There's no difference in outcome between the approaches when implemented correctly.

It's entirely up to you whether you prefer that stuff to be in the machine definition or not

[cedar kelp]

gotcha, so definitely need to look more into it, right now, just doing a few POCs