What is the xState way to compose side-effects with Inversion of Control?

[jLouzado]

From the docs#hierarchical-state-nodes:

Statecharts [...] encourage composability

However in practice I'm finding that once a child Machine has defined a side-effect it's not possible for the parent to control how that side-effect is performed.

For example a child enters a loading state by default, and fetches some data. If the parent wanted to cache the data or manipulate it in some way (or prevent the call in some situations) that doesn't seem possible.

Hence my question, is there a way to get composability of Machines where the full control is with the Parent (without the Parent having to be aware of the implementation details of the child)?

[Andarist]

Maybe I'm just not aware of ways how one could achieve this, but those 2 looks like opposing traits that can't really be achieved (unless you have things like algebraic effects or generators when the callee just describes an effect but the caller is actually responsible for executing it):

1. "get composability of Machines where the full control is with the Parent"
2. "without the Parent having to be aware of the implementation details of the child"

In general actors communication has to be explicit - if you want to influence the behavior of a child from a parent then you should communicate it with an event sent from a parent to a child, based on which a child could alter its behavior.

[jLouzado]

Yes, what I was after was this algebraic composition but I now understand that that's not compatible with the Actor model. Thank you for clarifying. 🙏

[davidkpiano]

The control/composability lies in being able to control what gets spawned. So if you wanted e.g., a custom fetcher, then this should stay the same:

invoke: {
  src: 'fetcher',
  // ...
}

And then controlled via options:

{
  services: {
    fetcher: () => createMachine(childMachineWithCaching)
  }
}

So, to answer your question, you wouldn't try to control the behavior of an invoked actor (that breaks the actor model); rather, you would create an invoked actor with the behavior you want.