Typescript and Extracting Compound States in Xstate5

[emarksamica]

I'm in the process of upgrading some of our existing state machines from version 4 to version 5. In our existing state machines, we have machines defined like this, where some compound states are extracted from the main machine, declared as their own variable, and referenced within the machine:

const STEP2States = {
  initial: "A",
  states: {
    A: {
      on: { NEXT: { target: "B" } },
    },
    B: {
      on: { NEXT: { target: "C" } },
    },
    C: {
      on: { NEXT: { target: "#machineId.STEP3" } },
    },
  },
};

const myMachine = Machine<{}, Events>({
  id: "machineId",
  initial: "start",
  states: {
    start: {
      on: {
        NEXT: { target: "STEP1" },
      },
    },
    STEP1: {
      on: {
        NEXT: { target: "STEP2" },
      },
    },
    STEP2: STEP2States,
    STEP3: {},
  },
  predictableActionArguments: true,
});

I've converted one of our machines to use the setup().createMachine() pattern, where actors/actions/guards implementations are declared, along with events/context/input defined in types in order to take advantage of the new TypeScript support in xstate5. Simple cases like the one shown above seem to work fine, but I've found that under certain circumstances, a compound state that successfully passes type checking validation when defined inline within the machine will fail if the same compound state is declared in a const and referenced that way instead. It appears that it takes issue with actor invocations and actions called within state transitions.

• In the case of actor invocations, our actors are referred to by an enum member. TypeScript seems to get hung up on the object representing the invocation's src potentially representing all members of that enum, instead of just the one that we actually used. I've managed to sort this out by changing this:

src: Services.MY_SERVICE,

to this:

src: Services.MY_SERVICE as Services.MY_SERVICE,

• In the case of actions, defining the action within the machine's setup and referring to it that way seems to fix it. So changing this:

        on: {
          MY_EVENT: {
            actions: assign({
              contextItem: ({event}) => event.myOutput,
            })
          }
        }

to this:

setup({
  actions: {
    'myAction': ({event}) => {
      assertEvent(event, 'MY_EVENT');
      assign({
         contextItem: event.myOutput,
       })}
  },
...

Similarly to the issue with declaring the invocation src, the actions have to be reasserted as not being string and instead as itself:

        on: {
          MY_EVENT: {
            actions: 'myAction' as 'myAction'
          }
        }

That said, even though these fixes should work, making these adjustments is beginning to feel like a code smell and I'm wondering if there might be a better approach to what we're doing here. Along with the above issues, we lose the advantages of being able to leverage auto-complete in vscode and get more insightful typechecking when working within our compound state.

I've also played around with establishing the type of the compound state as AnyStateNodeConfig, and while this fixes the actor/action issues and lets us take some advantage of auto-complete, it means we can't match on any of the child states within the compound state so the value of this approach is pretty questionable.

Is there any recommendation to how something like this should be approached? I believe some of our other xstate4 machines do this in order to have a reusable set of state nodes to be used across multiple machines, and before we tackle those I'd be curious if there's a better way to do this.

[HerbCaudill]

@emarksamica I'm struggling with this sort of thing as well. The only suggestion I have is that you can write 'myAction' as const, which is still annoying when you have to do it everywhere, but maybe feels a bit more natural than 'myAction' as 'myAction'.

[davidkpiano]

Sorry, I believe that this is currently a TypeScript limitation (cc. @Andarist)