Spectrum is now read-only. Learn more about the decision in our official announcement.


The Statecharts community on Spectrum is (along with spectrum) MOVING TO OTHER PLATFORMS: For statecharts discussions in general go to Statecharts Discussion on GitHub (link) or Gitter (link). For XState-specific questions, go to the XState discussion forum for Q&A or the Stately discord chat to chat.


FAQ for Managing Hierarchy of XState Actors in React

March 18, 2020 at 7:05pm

FAQ for Managing Hierarchy of XState Actors in React

March 18, 2020 at 7:05pm (Edited 2 years ago)
Reminder: Actors have completely private state and only communicate with messages.
How does this model fit into React and XState. Here are my recommendations right now from experimenting, as of xstate 4.7.6 and xstate-react 0.8.0. Please respond if you have found better solutions.. these are just a summary of my findings I thought I'd share.
tldr; Until actors in XState are more mature, the best way to communicate between shared services is not to use XState’s action types except for simple and shallow parent-child relationships. Instead, directly communicate with message passing between services managed by React components.

Should I spawn actors inside of XState or use the React model?

XState actor management is not mature enough to handle deep communication or other patterns like event busses. So, use React for now. Let React spawn actors and build the parent/child tree naturally by components.
  • You can use React Context for referencing parent state.
  • If a child needs to send a message to a parent, put that logic in callback props passed to the child i.e. onChange.
  • If a parent needs to send a message to a child, the child machine should subscribe itself to the parent and configure how it reacts to parent events.
  • If parallel actors needs to communicate with one another, they should all subscribe to a common event bus to configure how they respond. Then, the components can send events to the bus which will to forward them along to other parallel actors. You might need some helpers so that parallel actors can subscribe to only certain events from the event bus (like those with a certain ID).

How do I simplify sending messages to actors? Should I send to an event bus, Observable, actor, etc?

Do what Elixir does. They use actors in many of their libs, but most developers wouldn’t know it. They hide the message passing behind simple, straightforward APIs that handle the message passing for them. Do this with React hooks that use machines behind the scenes. Do this with React components by using callbacks.

How do I keep services decoupled but communicating? Where does all this wiring up happen?

Use decoupling strategies like event busses, Observables, and callbacks. Pass these into your machines. Keep actors ignorant of each other, and a channel (event bus) or API can be the smart one to hook them up. Custom React hooks can handle wiring up up these imports and translating prop changes into events.

What about deep message passing??

Use an event bus/channel that both top level and deep level actors subscribe to, and send your messages to the event bus to notify all relevant actors. XState machines can forward events to these channels, or an API level can redirect relevant events to the channels instead of the service.

What about deep state access i.e. user state deep in a screen??

XState does not have a great way of broadcasting state access to all children. Some ideas on how deep actors or components can access great-great-great-great-grandparent actor's context.
NOTE: most deep state access is for the purpose of UI, not state logic. If it is needed in state logic, the state and its updates can usually be represented by an event including the relevant state.
  1. Use React Context. Expose the top level actor/service through Context. Your child actors will need to be spawned by React instead of inside of XState, but that might be worth it until XState’s actor model matures. Since most state like this just needs to be used for display/rendering (not inside other machines), React will handle updates to it automatically. If you do need to update the state inside of a service, just use React hooks to send an UPDATE event when it changes.
  2. Use Observable streams. Instead of manually wiring up specific request/respond events, you can pass a stream around to always get the latest value. Instead of an event bus moderating, you’d use a stream. The parent component would hook up its context to the stream, and then the deep child component would import the stream through React context or a global registry like Redux/singleton.
  3. Use an event bus for requesting latest state. There would be some boilerplate, but you could hook up to an event bus that uses events to request a state from the publisher, and the publisher would send a response to all subscribers. Remember, the child would not know the state by default until it requested it. Since XState is not smart enough yet to communicate between services/actors started outside of XState, we can use an event bus and manually hook up the events. This is unfortunate boilerplate if the data is just used for rendering, but some helper code could simplify. NOTE: this could be an Observable to simplify.. see above.
  4. Use XState. Pass the state down through the actors. When the state is updated (like a User Setting change, you would manually propagate the USER_CHANGE event down through your child actors). However, this introduces the highest coupling, and it’s a poor representation of a much shallower relationship between the top-state and the child that needs it. Think about passing down an Observable hooked up to the parent's context if you’re limited to only managing machine through XState.
Show previous messages

March 25, 2020 at 1:25pm
Right - components can be considered actors!
.. and bus messages either through useContext or with Redux like john's example.
Or just prop drilling if components aren't to distant from each other.
Cooooool. This simplifies things a LOT. Much easier to work with.

March 27, 2020 at 10:34pm
I made a (very) simple example!
I like it because it feels the same as calling useMachine in a component, you just call useContext instead of useMachine!

May 7, 2020 at 11:00am
The consensus seems to be that XState loses its framework-agnostic status once you start having to manage multiple actors then? I'm building a multi-player board game and had this dream of XState for managing game and player state and having React just render the thing.
The consensus seems to be that XState loses its framework-agnostic status once you start having to manage multiple actors then?
Not exactly. At a certain point, you're fighting the framework over control of the state, since the framework wants to be control of more state. It's possible to use XState in a completely framework-agnostic way, but that may require doing things that aren't that idiomatic in that framework unfortunately.

July 7, 2020 at 5:24am
Just came across this thread, and I'm terribly confused now...especially with the example codesandbox. Is this saying not to use actors (as in XState actors) at all, and just share one machine across components (either through props or context)?

July 7, 2020 at 7:52pm
Correct. When using XState + ReactJS I've found using props or context to communicate between sibling- or hierarchically related components more efficient. Primarily because ReactJS is the "mother" framework here sitting on top of XState. The hierarchical concept of actors as children of machines does not translate one-on-one to a component hierarchy. E.g. when using actors, messages are sent from actors up to parent machines and from parent machines to parent components and back down to child components. Not from actors directly to nested child components.
We're not saying "don't use actors". Only trying to clarify that actors don't directly communicate with components and only via the machine that spawned them.

July 8, 2020 at 3:03am
I'm just trying to understand when you'd use actors. Let's say I'm creating a todo application, so the examples I've seen have you spawn a new actor for each "todo item" But instead you can "spawn" an actor by rendering a new component with it's own machine. Communication just happens by passing props down to that component, and the component sending events back up.
So where do actors fit in?

July 8, 2020 at 1:36pm
you can "spawn" an actor by rendering a new component with it's own machine Exactly. The component is the actor here. We're just choosing not to use the XState specific API for spawning actors directly by a parent machine but rather letting ReactJS be the actor system here
Out-of-the-box it is difficult to let actors spawned by machines be in charge of the UI/DOM when using ReactJS.
Letting ReactJS be the system managing the messaging between systems just makes more sense
Yeah I got that. My question is when do we use actors? I haven't yet used them yet, but twitter makes it seem like actors were a very big deal...perhaps a gamechanger in frontend architecture. I was wondering I was missing something? So is there a use case for actors? Do I not have to feel guilty that I haven't used them?
I've been using XState extensively (with ReactJS) and I have yet to use actors, so no, you do not have to use actors.
Or feel guilty about that.

July 9, 2020 at 2:58am
Don't feel guilty for not using actors - but they will be a game-changer, especially since they've been around since the 1970s and have already been a game-changer for server-side code. Time to bring it to the front-end! It's useful to conceptualize your code as actors.
  • A promise is an actor that doesn't receive any events and only ever sends back one event (at most).
  • An observable is an actor that also doesn't receive any events and sends back 0 - infinite events.
  • A service (interpreted machine) can send and receive any number of events.

July 9, 2020 at 1:02pm
My issue with communication inside React with Context is how to handle updates . For example lets say we have two machines A,B and when A reaches the final state it needs to send an Event to B . If you handle that inside React you need to do it inside a useEffect , to check if the state is final and then send an event to B .

July 10, 2020 at 1:45pm
That's not necessarily bad though. It's just one of the ways to make the 2 systems "talk" to each other.
I've also resolved this by forwaring incoming callback props via event payloads E.g. A component that receives a callback prop, say props.onContinue, renders:
<SubmitButton onClick={() => send({type: 'SUBMIT', onContinue: props.onContinue }) />
That gives the machine access to props.onContinue rather than using useEffect. The machine might invoke an asynchronous service and in it's onDone configuration access evt.onContinue
Yes but there is a problem with that solution . If your machine transitions to error or success state after on submit event and you need to consume the onContinue function only in the success state then you need to assign the onContinue in context in order to consume it .
Not necessarily. You can propagate the callback to the done or error event
states: {
submitting: {
invoke: {
src: (_, evt) => Promise.resolve(42).then(n => [n, evt.onContinue]
Which would result in a DoneInvokeEvent<[number, () => void]>
Yes but dont you think that if they states are not close to each other then you have a "callback" drilling ?

July 16, 2020 at 1:37pm
Since it's been a while when this was posted, I do believe that XState's actor communication has matured quite a bit. With respond, forward and escalate as well as the pureaction creator being introduced, there is quite a lot we can do with plain XState without the need to invoke a lot of machines from within React. I'm usually only invoking the top most actor from within React and have had 6-7 level deeply nested actors without the need for an event bus. Sometimes I use explicit event forwarding e.g I want to send an event from A to C. B may define the same event as C and just has an action "forwardEventToC".
It does get more tricky when you need to route an event from A to C5 to E12 assuming that some actors like B and D spawn multiple child actors of the same type. In this case, you'd need to include the ids as well and at some point I would too reach for an event bus solution as proposed here. However, thus far I didn't have the need to do so.
TL;DR: Try to reach the limits of plain XState message passing before going for more complex solutions.
Show more messages