getSnapshot() type is not a union - bug or feature?

[dearlordylord]

Hi, for getSnapshot() xstate returns the values with type having optional keys, i.e. {a?: ..., b?: ...}

It's described in tests here:

xstate/packages/core/test/setup.types.test.ts

Line 1224 in 3fb895f

it('should type the snapshot state value of a nested statechart using optional properties for parent states keys', () => {

Pasted test is:

const machine = setup({}).createMachine({
      initial: 'a',
      states: {
        a: {
          initial: 'a1',
          states: {
            a1: {},
            a2: {}
          }
        },
        b: {
          initial: 'b1',
          states: {
            b1: {},
            b2: {}
          }
        }
      }
    });

    const snapshot = createActor(machine).getSnapshot();

    type ExpectedType = {
      a?: 'a1' | 'a2';
      b?: 'b1' | 'b2';
    };

    snapshot.value satisfies ExpectedType;
    ({}) as ExpectedType satisfies typeof snapshot.value;

My question is shouldn't ExpectedType instead be a union such as {a: 'a1' | 'a2'} | {b: 'b1' | 'b2'} (or | {} if we assume no state is allowed)?

My source of confusion is that the model { a?: 'a1' | 'a2'; b?: 'b1' | 'b2'; } allows both 'a' and 'b' present, so machine (as described in types) can have both types, despite them not being declared as parallel.

I stumbled upon this behaviour trying to exhaustively match the states with switch.

[Andarist]

I was debating with myself how this should work when implementing this. My intuition was that it kinda should be a union but at the same time, it wouldn't be a discriminated union. Given that making it a union would be slightly more convoluted I decided to go with the easier option.

This is something that we could revisit! It could impact some code out there (remember that you can't access a key that is not present in all union members) but we still might want to consider it.

I stumbled upon this behaviour trying to exhaustively match the states with switch.

Could you show me how you have wanted to match against this?

[Andarist]

I'm not sure if I'm sold on changing this just to make ts-pattern more happy. Please don't get me wrong, it's an awesome library! It's not used by everybody though and changing this now could affect some code that people write today. I'm also not saying that we won't change this but I think I'd prefer to wait a little bit before making any decisions related to this.

You could always create a type-level converter that would convert the current shape of this value into something that would be more friendly to ts-pattern. This would require some casting but I wouldn't classify a cast like this to be particularly bad and you could always hide it in an utility function.

[dearlordylord]

Thank you. I'm going with type converted for now. Hope to see those unions one day, because it's not just about ts-pattern to me but about domain model that state machines represent (i.e. {a?: ..., b?: ..., c?: ...} means to me the machine is allowed to be in all states at the same time or in any combination of them, which is misrepresentation!).

[PorcoRosso85]

I seem to want to achieve the same thing with Firfi, because xstate is great. If I could take advantage of the xstate design language, I would rely on xstate to design some large projects.
@Firfi may I ask, did you have any problems constraining the ts-pattern?

The reason why I ask because...
It seems that the StateConfig type 1st argument of the now completed createMachine() is not exposed by the library, so the State type of this code is never
The code described below makes the first argument a separate object, but there is also the problem that updating it with the vscode extension collapses the object. I am thinking that once we can get the first argument from the createMachine() instance from this, we can move on to using ts-pattern, maybe...

export const authMachine = createMachine(authStates, {
  actions: {},
  actors: {},
  guards: {},
  delays: {},
})

const authStates = {
  id: 'auth',
  initial: 'isNotUser',
  states: {
    isNotUser: {
      on: {
        GetUserQuery: {
          target: 'isUser',
        },
      },
    },
    isUser: {
      always: {
        target: 'isNotAuthenticated',
      },
    },
    isNotAuthenticated: {
      on: {
        signJwtToken: {
          target: 'isAuthenticated',
        },
      },
    },
    isAuthenticated: {
      on: {
        logout: {
          target: '#auth',
        },
      },
    },
  },
  on: {
    loginRequest: {
      target: '.isNotUser',
    },
  },
  types: {
    events: {} as
      | { type: 'GetUserQuery' }
      | { type: 'signJwtToken' }
      | { type: 'logout' }
      | { type: 'loginRequest' },
  },
}

type States = keyof typeof authMachine.config.states
type Events = ''

const authMatch = (state: States, event: Events) =>
  match([state, event])
    .with(['isNotUser', 'GetUserQuery'], () => '')
    ...
    .exhaustive(

[PorcoRosso85]

I will open another DISCUSSION if possible.

[dearlordylord]

Better to move to another discussion yes @PorcoRosso85 but my initial intuition is that I remember there was something else I had to do to make it better at type-level

probably:

import { setup } from 'xstate';
...

setup({
...
  types: {} as (typeof authStates)['types'],
}).createMachine(authStates)

also make sure you use strict: true and add as const; to your authStates