useMachine... sometimes :D

[geddski]

I'm making a game that has a lot of characters. Each character has:

• a state machine
• a service
• a React component

Each Level of the game uses only a handful of the characters. e.g. Level 4 uses character1, character6, and character19. Level 5 uses character2 and character8.

My root component (Level) initializes all the characters' machines/services, and passes them down to their corresponding React component. This way the Level can send messages to all the services.

Level is using useMachine(...) to create the machines/interpreters for the characters. Trouble is, with React's hook limitation (no conditionals), Level ends up creating all characters' machines & interpreters, even for characters that aren't used during that Level. This feels wasteful and could impact the game's performance.

This is a React limitation that doesn't have a great workaround as far as I can tell. Maybe useMachine could sometimes be a noop/return undefined, but that might not be fun for TS users...

Another thought would be to not use useMachine, and just use Machine() directly in my own custom hook. I'd probably need to reimplement all the cases that useMachine handles though. Unless useMachine's logic could be pulled out into a regular function util or something. Just thinking out loud here.

[Blacktiger]

You might think about having the level machine spawn new actors for each character based on the current level. Extract the logic from React into the machine.

[geddski]

@Blacktiger I've been a little afraid of giving up lifecycle control, so I haven't used spawn & friends much. I need the services to stay alive as long as the Level react component is mounted. Is there a way to do that with spawn, or is it more for temporary machines that are used as services?

[Blacktiger]

You should store a reference to the spawned actor in your Level machine. I believe when the Level component is cleaned up (and thus the level machine) the actors will be cleaned up as well so the lifecycle management should be handled automatically.

[fraserdrops]

The line between invoke and spawn is blurry but when I've used them the main difference has been that with invoke the service is 'scoped' to a particular state (including the root state). When you leave the state you've invoked the service in it stops. With spawn, the services aren't really tied to any state in the parent machine, they're part of it's context. You can start and stop them at any time, and also create them dynamically. They will stay around as long as the parent exists if you want them to. (This is my understanding, someone please correct me if it's not right).

I would have said that spawning characters in the Level machine makes sense conceptually. However, I've found that it can be really difficult to map an XState model onto a React component hierarchy, and it's a trade-off between getting a nice XState model and actually being able to use it in React.

[Andarist]

The line between invoke and spawn is blurry but when I've used them the main difference has been that with invoke the service is 'scoped' to a particular state (including the root state). When you leave the state you've invoked the service in it stops. With spawn, the services aren't really tied to any state in the parent machine, they're part of it's context. You can start and stop them at any time, and also create them dynamically. They will stay around as long as the parent exists if you want them to. (This is my understanding, someone please correct me if it's not right).

Thats a very good understanding of the differences.

However, I've found that it can be really difficult to map an XState model onto a React component hierarchy, and it's a trade-off between getting a nice XState model and actually being able to use it in React.

Could you showcase how u have tried to tie both? I could come up with advices on how it could be improved.

[geddski]

Yesterday I learned that you actually can break this first rule of hooks without any issues, so long as the hook order remains invariant. For config cases like mine, this is awesome news. I tried using useMachine conditionally based on config and it works without problems.