Actions & guards, dependencies and sequence

[Perlkonig]

I know the problem is me not understanding the correct patterns. I appreciate your patience with this very linear thinker 😄

I'm coding a relatively simple solitaire dice game. The main complexity is that at various points throughout the game, the player has access to certain powers, and the engine needs to pause at these points for input. Here's an extract from the state chart:

searching: {
    initial: "settingup",
    entry: ["setSearchStage"],
    states: {
        settingup: {
            always: [
                {
                    target: "assigning",
                    cond: "interruptsResolved"
                },
                {
                    target: "interruptingSetup"
                }
            ]
        },
        interruptingSetup: {
            exit: ["resolveInterrupt"],
            on: {
                RESOLVE: "settingup"
            }
        },
        assigning: {

So when entering the searching state, the action setSearchStage prepares the context, including producing a list of powers the player has access to at this point in the game. The engine should then move to the settingup state where the interruptsResolved guard gets called. If the length of a certain array is 0, then it moves to the assigning state. Otherwise it moves to the interruptingSetup state where the player can issue a RESOLVE event with a payload to resolve those interrupts, which are then tested again by going back to the settingup state.

The problem is that the interruptsResolved guard is getting called before the setSearchStage action. The docs make it clear that actions are called by the interpreter as a batch after the machine state has settled, so I assume the problem here is the transient state settingup. But I'm not sure what the idiomatic way to deal with this is. What's the "correct" way in the FSM paradigm to deal with this sort of logic?

Thanks for your time!

[mattpocock]

Hello! Could you call the action setSearchStage on the transition to the searching state?

{
  target: 'searching',
  actions: ['setSearchStage'],
}

This would mean it gets called and the context resolved before it reaches the 'searching' state.

[mattpocock]

Could you send over a reproduction? I've tried to reproduce what you're referring to in this codesandbox but it appears to be working for me. Node that the console.log inside the guard is logging the data supplied by the assign.

Let me know if I've got anything wrong

https://codesandbox.io/s/falling-star-1u3b5?file=/src/index.ts

[Perlkonig]

Thanks for your time, Matt. So maybe the problem is I'm doing the action wrong. Right now setSearchStage just does stuff with the context. But what I fear after reading your code and the assign documentation is that those mutations are not being saved. Your code and the docs, though, also only show assign being used inline with the state definition.

Right now setSearchStage is an action defined inside the machine.

setSearchStage: (context, event) => {
    const node = {};
    /*a bunch of logic to determine what the various properties of this object are*/
    context.data = node
}

If I'm reading things right, the correct approach is to abstract that logic to a separate function outside of the machine and then rewrite things as follows:

searching: {
    initial: "settingup",
    entry: [assign({ data: context => externalFunction(context) })],
    states: {
        settingup: {

Or is there a way to mutate the state in the action itself (which would be cleaner)?

[mattpocock]

Aha, yes, this is it. The assign function needs to return a partial of the new context you need. So for instance:

// context is { name: 'Matt', username: 'mattpocock' }

assign(() => {
  return {
      username: 'patmocock'
    }
})

This would assign the 'username' attribute in context to 'patmocock.'

You can also mutate the state within the action itself by using @xstate/immer, which means the above action could read:

import { assign } from '@xstate/immer';

// context is { name: 'Matt', username: 'mattpocock' }

assign((context) => { context.username = 'patmocock' })

Let me know if that helps.

[mattpocock]

And so we're clear, calling assign creates an action which you can pass into your machine, wherever you need it. It can be inline in the machine:

const assigner = assign(() => {
  return {
      username: 'patmocock'
    }
})

const machine = Machine({
  entry: [assigner]
})

Or in a .withConfig:

const assigner = assign(() => {
  return {
      username: 'patmocock'
    }
})

const machine = Machine({
  entry: ['assignPatMocockToContext']
}).withConfig({
  actions: {
    assignPatMocockToContext: assigner,
  }
})

Or in the other ways XState allows you to do this, such as passing options to interpret or useMachine functions.

[Perlkonig]

I feel bad that this has completely gone off from the original question, Thank you again for your time.

So it now appears to be working as expected. Since my context is a class, I had to mark the class as "immerable" first. Then I was able to delete the previous action that was defined in the machine definition and replace it with a constant assigner function defined outside of the machine, as follows:

import { assign } from '@xstate/immer';

const setSearchStage = assign<MyContext, MyEvents>((context, event) => {
    const data = {};
    /* A bunch of logic to populate `data` */
    context.data = data;
});

/* Start of machine definition */
            searching: {
                initial: "settingup",
                entry: [setSearchStage],
                exit: ["leaveArea"],
                states: {
                    settingup: {
/* Rest of machine definition */

So I will mark the question as answered, but people will have to read down to see that my original question was misguided in the first place. Thanks for the help!

[Perlkonig]

I feel bad that this has completely gone off from the original question, Thank you again for your time.

So it now appears to be working as expected. Since my context is a class, I had to mark the class as "immerable" first. Then I was able to delete the previous action that was defined in the machine definition and replace it with a constant assigner function defined outside of the machine, as follows:

import { assign } from '@xstate/immer';

const setSearchStage = assign<MyContext, MyEvents>((context, event) => {
    const data = {};
    /* A bunch of logic to populate `data` */
    context.data = data;
});

/* Start of machine definition */
            searching: {
                initial: "settingup",
                entry: [setSearchStage],
                exit: ["leaveArea"],
                states: {
                    settingup: {
/* Rest of machine definition */

So I will mark the question as answered, but people will have to read down to see that my original question was misguided in the first place. Thanks for the help!