One shared instance between multiple React components

[miloslavnosek]

If I wanted to share a single instance of my state machine in multiple React components, how would I go about it? The way I see it there are two possible solutions:

• A standard file with a state machine that exports all the functions for interacting with it. This doesn't strike me as a solution that integrates well into React. I bet there is a better way to go about it which uses built-in React features.
• Integrating it into React context. Here I'm not sure if it's a good idea since the state will be held in the state machine itself rather than in the context and it might have a bunch of unnecessary code. On the other hand it feels more "right" when it comes to integration with the library.

or maybe there's another way that I'm missing.

[Andarist]

Both are IMHO OK. Regarding your „state will be held in machine rather than in context” part - isnt this part if the point of using a machine? This works pretty much the same as with Redux - you externalize the state from React (either to XState or to Redux) and use context to subscribe to changes.

[miloslavnosek]

Yeah, it is. I only mentioned that part because when working with context in React, the standard practice is to make the context itself have state instead of something else and I thought it would defeat the purpose of the context API but I wasn't quite sure of that because I think this API is something that was made specifically for situations where multiple components need to share state and be able to alter it.

[davidkpiano]

I'm currently writing an article on this, but I'd recommend doing it through context:

const ServiceContext = React.createContext();

const App = ({ children }) => {
  const [_state, _send, service] = useMachine(someMachine);

  return (
    <ServiceContext.Provider value={service}>
      {children}
    </ServiceContext.Provider>
  );
}

// in a child...
const Child = () => {
  const service = React.useContext(ServiceContext);
  const [state, send] = useService(service);

  // ...
}

The pattern above feels pretty natural and idiomatic to React.

[sebastienbarre]

@davidkpiano this is nice, but I'm struggling with sharing the same service between several UI components while having different side effects (aka different actions). Actions are part of the useMachine() configuration, whereas I would like to set them with useService().

To quote the doc: "Actions are fire-and-forget effects. For a machine to be useful in a real-world application, effects need to occur to make things happen in the real world, such as rendering to a screen.". In my use-case, the same event sent to the shared machine would trigger different side-effects (say, two different UI component would then asynchronously fetch different data to refresh themselves).

For example, in my machine:

    LOGGING_TIMERS: {
        invoke: {
          src: 'logTimers',
          onDone: {
            target: 'IDLE',
            actions: ['onLogTimersCompleted'],
          },
          onError: 'IDLE',
        },
      },

Here, onLogTimersCompleted is the action I wish could be different per component sharing the same state machine service instance, since in my app two components of mine will have different side effects after the successful completion of logTimers.

NOTE: David and others were kind enough to provide potential solutions in #2330
Thanks

[pke]

Sure, you can do this:

<ServiceContext.Provider value={{ send, subscribe: service.subscribe }}>
  { children }
</ServiceContext.Provider>

If you want values, subscribe to the service in a useEffect in the component and save those to state.

Be aware that this creates an unstable value, which causes re-renders of the providers children even when neither send nor subscribe change.

[redbar0n]

@pke why will it do that?

[RemyMachado]

@pke why will it do that?

The value isn't memoized, a new object value={{}} is created at every render, thus provoking unnecessary re-renders among the children.

[RemyMachado]

The pattern above feels pretty natural and idiomatic to React.

I can only agree with your statement @davidkpiano

Wouldn't it make sense to make this behavior part of the library?

I believe exposing a hook that would subscribe to createActorContext's provider would be great.

[EvanLovely]

What about using a singleton where the machine is started in its file and the running service is exported? Then every other file importing it would get the same running service? This has been working for me; anything I'm missing?

// my-service.js
const myMachine = Machine();

export const myService = interpret(myMachine);
myService.start();

Then in multiple other files:

import { useService } from '@xstate/react';
import { myService } from './my-service';

const MyComponent = () => {
  const [state, sendEvent] = useService(myService);
}

import { useService } from '@xstate/react';
import { myService } from './my-service';

const MyOtherComponent = () => {
  const [state, sendEvent] = useService(myService);
}

[Andarist]

Nope, a fine approach if ur machine has to outlive components

[redbar0n]

how to have myService.start() only run on first appearance in the app?

[mattpocock]

@redbar0n If you want to tie a service's lifecycle to the lifecycle of a component, I'd just use useInterpret

Or, start the service (if not already started) in a useEffect on first render.

[VILLAN3LL3]

How to achieve this in the current xstate versions? useService is no longer available and React.createContext() without supplying a parameter is no longer permitted. I tried to follow https://xstate.js.org/docs/recipes/react.html#global-state-react-context, but didn't get along with the type errors. I think the beta typesystem for typescript is not yet sufficiant to do that

[davidkpiano]

There's also a much simpler way if you don't want to use context:

import { createActor } from 'xstate'; // xstate@beta

export const actor = createActor(someMachine).start();

// Use anywhere
import { useSelector } from '@xstate/react'; // @xstate/react@beta
import { actor } from '../path/to/actor';

const Component = () => {
  const count = useSelector(actor, s => s.context.count);

  // ...
  // can directly call `actor.send(...)`
}

[with-heart]

@davidkpiano Yummy!

[VILLAN3LL3]

@with-heart Thanks for the link to the beta docs. I already tried this but couldn't get it working with typescript. createContext requires either a generic type or a typed default value. If I use any I loose the type safety in the dependent components. And although I use the xstate type generator and defined an explicit type for the events, it doesn't recognize it in this case.

I created a small demo project to demonstrate the issue: https://github.com/VILLAN3LL3/github-issue-xstate-1754/tree/initial

[davidkpiano]

You can use the createActorContext(...) helper function: https://stately.ai/blog/2023-1-27-making-state-machines-global-in-react

[VILLAN3LL3]

This is really cool - and it works! Thank you, @davidkpiano !! (I updated the GitHub demo)

[kolorfilm]

You can use the createActorContext(...) helper function: https://stately.ai/blog/2023-1-27-making-state-machines-global-in-react

It works but I have some trouble to get createActorContext mocked in jest and test different states for "the actor".

I described it in the offical discord channel from Stately as well. You can find it here.

It is basically about that: Someone else had the problem as well.