Redux "middlewares" solve a problem. How would I solve the same problem in XState?

[alavkx]

The middleware pattern solves a problem

It provides a third-party extension point between dispatching an action, and the moment it reaches the reducer. People use Redux middleware for logging, crash reporting, talking to an asynchronous API, routing, and more.

I've been posed a question that boils down to—"How can I do middlewares in XState? I need middlewares."

How do you solve for "middlewares" in XState? Is this sort of logic re-use a non-problem? Do you compose? Does XState not attempt to solve for logging, crash reporting, etc..?
I've attached my answer below, but I'm curious of everyone else's thoughts❗ 🙏 💟

---

Instead of middlewares, you’d probably compose machines. For example if you want an auth middleware, you make an authMachine. Other state machines can use that authMachine as a service. https://xstate.js.org/docs/guides/communication.html#invoking-machines

Here is an example of an authMachine https://github.com/cypress-io/cypress-realworld-app/blob/develop/src/machines/authMachine.ts
and if you want to run that service at the start of your app, following a sort-of-singleton pattern, you can do that
https://github.com/cypress-io/cypress-realworld-app/blob/develop/src/machines/authMachine.ts#L163-L169
https://github.com/cypress-io/cypress-realworld-app/blob/92cd8604b24f56556e42447f051b6af006450610/src/containers/App.tsx#L31

[nomadtechie]

Thanks so much for filing this @alavkx! I'm eager to watch this thread - I need to do some more research before I can chime in a meaningful way but this topic is is certainly worth an open discussion. Tagging @markerikson who might want to chime in or lurk.

[rjdestigter]

Former Redux fanatic and functional programmer who absolutely loves to solve everything using function composition here. I haven't missed middle-ware so far. State machines manage both data and effects so any effect related middle like redux-saga or thunks became irrelevant. To log events and transitions I just use a wrapper around useMachine.

Authentication state (so far the only state that I've had to use across machines and components) is shared using a push based stream. This is handy because streams can be converted to promises allowing me to either subscribe to the stream in the machine or even use them in promise chains when I make network calls.

[davidkpiano]

Excellent question! What exactly are you trying to do with middleware in XState (e.g., logging, etc.)?

Keep in mind that the main mechanism for how XState (and the actor model, in general) works is message passing (with events), so the only real opportunity to "do something" with an event is to intercept it before it reaches an invoked machine.

For example, if you wanted to add logging before an event reaches a machine:

const service = interpret(someMachine).start();

const sendWithLog = (event) => {
  console.log(event);
  service.send(event);
}

const wrappedService = {
  subscribe: service.subscribe,
  send: sendWithLog
}

wrappedService.send('HELLO');
// => { type: "HELLO" }

Note that you can also use a reactive approach instead of using middleware, by adding observers:

// Logs the event after it was sent to the service
service.subscribe(state => console.log(state.event));

But I'd like to know more of your use-cases. There are advanced use-cases in which machines themselves can be "middleware", and use forwardTo(...) to forward events to invoked machines.

[EdmundsEcho]

I agree that xstate and other options exist for dealing with side-effects (e.g., I like sagas). For me, it's mostly about where it make sense to encapsulate the functionality (intuitive and easy to maintain).

I'm in the process of plugging in an xstate machine to manage an api call that requires a polling service (a service the user can cancel; a service that will restart automatically as needed when reloaded). This service will be provided by the xstate machine and instantiated using middleware. The logic is surprisingly tedious; xstate will encapsulate the complexity to provide the middleware a much simpler, message-driven interface.

I also use middleware to normalize the raw data served from the api (ready-payloads for the reducers), for logging and augmenting the messaging capacity when things go wrong.

- E