Allow spawn(<machine>) to accept an optional starting state

[Alex-Yakubovsky]

What

It'd be handy to set the initial state when calling spawn(<machine>), something like

spawn(myMachine, <SpawnOptions>, { state: <desired initial state> })

Problem I'm Trying to Solve

I'm building out a small game in which there is a gameMachine and a playerMachine (each player gets an instance of playerMachine). The gameMachine spawns a playerMachine actor whenever a player joins. The game can be in the lobby state or in the playing state, if a player joins while the game hasn't started yet, their initial state is "waiting". I'd like for players to also be able to join while the game is being playing, in which case the initial state for the player that join mid game machine should be "playing". Also open to suggestions if I'm approaching this wrong 🙂

[Andarist]

Where that "desired initial state" is coming from? How do you get to know it within your app?

[Alex-Yakubovsky]

^ this would be running server side

[Andarist]

Wouldn't a conditional initial state in the playerMachine make for a better model here? Smth like:

initial: [{
  cond: (ctx) => ctx.isPlaying,
  target: 'playing'
}, {
  target: 'waiting'
}]

[Alex-Yakubovsky]

That would work, my only thought here is that ctx.isPlaying and the the "playing" state represent the same information, it'd be nice to have a single source of truth.

A computed initial state could be handy:

initial: (ctx, init) => init.isPlaying ? 'playing' : 'waiting'

or with a similar api as .withConfig and .withContext; .withInitial. So I could do something like:

const playingPlayerMachine = playerMachine.withInitial('playing').withContext({ .... })
spawn(playingPlayerMachine)

[Andarist]

The ctx.isPlaying was just an example of smth that u could base your decision on. Your init proposal~ is pretty much implemented in v5 as input (we dont - yet - have dynamic~ initial states there though but there is a plan to introduce them)

[Alex-Yakubovsky]

gotcha, I'll keep an eye out for that!