Code review for xstate code for an upcoming YouTube video

[jherr]

I'm doing a multi-part YouTube series on building a JackBox TV style game using xstate and GraphQL subscriptions. It all works, but I don't feel like the xstate machine is what it should be.

In particular I don't like this code: https://github.com/jherr/firsties/blob/master/server/game.ts#L42-L48

I just need to set a response and then go on to the next state if all of the responses are filled in. Seems simple enough, but I've tried a few different techniques and nothing has worked. What I have now is the cleanest I've been able to get to.

[davidkpiano]

For reference, here's the code:

updateResponse: {
    actions: ["updateResponse", send("checkResponses")],
},
checkResponses: {
    target: "VOTE",
    cond: "everyoneResponded",
},

You can also do this:

updateResponse: [
  { target: 'VOTE', cond: 'everyoneResponded', actions: 'updateResponse' },
  { actions: 'updateResponse' }
]

Which reads like:

Go to vote if everyone responded, and update the response. Otherwise, just update the response.

You might feel uneasy about the repetition in the 'updateResponse' action, but it's more clear/explicit than:

Always update the response and go to vote if everyone responded.

You can always create a helper function to remove the repetition:

function alwaysDoActions(transitions, actions) {
  return transitions.map(transition => ({
    ...transition,
    actions
  }).concat({ actions });
}

// ...

updateResponse: alwaysDoActions(
  [{ target: 'VOTE', cond: 'everyoneResponded' }],
  'updateResponse'),

// ...

IMO I'd rather just have the repetition instead of adding another abstraction.

[jherr]

Ok. So we are setting on of multiple responses. So everyoneResponded would need to be, hasEveryoneExceptThePersonRespondingWithThisEventResponded. Though that wouldn't be a great title.

I think I get it though. Would it be possible to have a postCond on an event handler? Where the postCond is checked just like the cond, but after the action happens?

[davidkpiano]

I think I get it though. Would it be possible to have a postCond on an event handler? Where the postCond is checked just like the cond, but after the action happens?

Not according to SCXML. This isn't a shortcoming, but rather reveals that these are two separate states (which is a bit of a mental shift from traditional procedural programming). There is:

1. the state in which the action is executed (no matter what)
2. the state afterward in which the condition is checked before transitioning

With your logic, you can only get to the second state from the first state - that is, the action must be executed before checking the condition (which is technically the same as a "postcond").

Statecharts force you to be explicit, and the structure guides you towards that. A postCond (or similar) helper can be added in userland.

[jherr]

Ok. That makes sense. Thank you for the explanation, that was super helpful.