Different context per state?

[jmagaram]

I'm trying to wrap my head around xState and don't understand something. In functional languages I define states using discriminated unions like...

type SignInState =
| CollectingCredentials
| Error of string
| SignedInAs of Email
| SignedInAnonymously

So each state has unique data for that state. So if I want to draw the Error state I can write "Something went wrong: {Error}"

In xState it doesn't seem like this is how it works. It looks like one Context is shared by all the possible states. So an Error message exists for all states, though it might be null or undefined for some.

Is this correct? And if so, is that a technical limitation or the way we really want it to work?

---

As a side note I did build my code using a hand made type-safe Typescript function. Action -> State -> State. I sprinkled in some side effects. It works but it was super tedious to write with all the Switch statements. Doesn't do hierarchical or history or visualization but it works. So I thought maybe xState would make this easier (and a lot shorter) and ran into the conceptual problem described above.

[Andarist]

Is this correct? And if so, is that a technical limitation or the way we really want it to work?

I'm not familiar enough with functional languages to know how this works there but in TypeScript this ain't super trivial right now. You can actually use typestates to achieve what you want but note that this is not type-safe.

[jmagaram]

So I think you are saying that yes it is desirable/good to have different context per state, like my original discriminated union example. But technically it can't be done right now in a type-safe way. Correct? Also I think xState builds on SCXML. I don't know much about this. But I'll also assume that those standards also endorse state-specific context. So when people use xState they are probably bumping into the same problem I was - putting something in Context that is irrelevant/confusing for many/most states just so it can be accessible in a small number of states where it is relevant.

[Andarist]

So I think you are saying that yes it is desirable/good to have different context per state, like my original discriminated union example

Yes, usually this makes sense 👍

But technically it can't be done right now in a type-safe way. Correct?

Yes, correct - not with pure TS (to the best of my knowledge).

Also I think xState builds on SCXML. I don't know much about this. But I'll also assume that those standards also endorse state-specific context.

Actually, SCXML doesn't touch this subject at all - the context (or the datamodel - as this is how SCXML calls it) is just an object~ which doesn't depend on the current state anyhow. It's a single context for a given machine's instance.

So when people use xState they are probably bumping into the same problem I was - putting something in Context that is irrelevant/confusing for many/most states just so it can be accessible in a small number of states where it is relevant.

This is definitely something we'd like to address in the future. My best bet is on the tooling built around XState and TS that could actually analyze the graph and validate the supplied typestates information. Right now this is just an idea which we don't have the capacity to pursue right away though.

[jmagaram]

I tried to use the Typestates feature but it wouldn't let me add any properties for a state that don't exist in the Context; I think this is consistent with the documentation that talks about using Typestates to narrow the context. Then I tried using the first published mechanism for using Typescript (which still doesn't permit per-state context) and noticed that it is possible to specify a target transition state that does not exist and NOT get an error. So I tried to create my own simple state machine that (1) is totally type-safe, (2) permits per-state context, and (3) uses a user-friendly hierarchical state definition like xState. And it works great. See the code below for example. So I'm really confused about what makes per-state context so difficult to do in a type-safe way. Maybe when you add hierarchical features or parallel states then it gets significantly more difficult?

interface StateCore<SKEY> {
  state: SKEY; // discriminator kind/type
}

interface EventCore<EKEY> {
  event: EKEY; // discriminator kind/type
}

type Transition<SOURCE, EVENT, TARGET> = (
  s: SOURCE,
  e: EVENT
) => TARGET | undefined;

interface Machine<
  S extends StateCore<SKEY>,
  E extends EventCore<EKEY>,
  SKEY extends string = S['state'],
  EKEY extends string = E['event']
> {
  initial: S;
  states: {
    [SK in S['state']]?: {
      [EK in E['event']]?: Transition<S & StateCore<SK>, E & EventCore<EK>, S>;
    };
  };
}

// Just keeps track of current state and proesses incoming events (which might
// update the state).
class Interpreter<
  S extends StateCore<SKEY>,
  E extends EventCore<EKEY>,
  SKEY extends string,
  EKEY extends string
> {
  state: S;

  constructor(readonly machine: Machine<S, E, SKEY, EKEY>) {
    this.state = machine.initial;
  }

  send(event: E) {
    const stateNode = this.machine.states[this.state.state];
    if (stateNode !== undefined) {
      const eventNode = stateNode[event.event];
      if (eventNode !== undefined) {
        const target = eventNode(this.state, event);
        if (target !== undefined) {
          this.state = target;
        }
      }
    }
  }
}

// =========================================================================
// An example state machine that is either in the 'dormant' or 'calculating'
// state. When 'calculating', it tracks a single value that gets incremented
// each time an 'increment' event happens.
// =========================================================================

type StateKey = 'dormant' | 'calculating';

type State<T extends StateKey> = T extends 'dormant'
  ? { state: 'dormant' }
  : T extends 'calculating'
  ? { state: 'calculating'; value: number } // state specific context
  : never;

type EventKey = 'start' | 'increment' | 'abandon';

type Event<T extends EventKey> = T extends 'start'
  ? { event: 'start'; initialValue: number }
  : T extends 'increment' | 'abandon'
  ? { event: T }
  : never;

const counter: Machine<State<StateKey>, Event<EventKey>, StateKey, EventKey> = {
  initial: { state: 'dormant' },
  states: {
    dormant: {
      start: (s, a) => ({ state: 'calculating', value: a.initialValue }),
    },
    calculating: {
      abandon: (s, a) => ({ state: 'dormant' }),
      increment: (s, a) => ({ state: 'calculating', value: s.value + 1 }),
    },
  },
};

[Andarist]

Maybe when you add hierarchical features or parallel states then it gets significantly more difficult?

One of the major reasons - especially parallel states are challenging.

In XState we use assign to update context value which also makes this harder because it's hard to "prove" at the type level things like [assign(), choose([{ cond: () => true, actions: assign() }])].

And... we have compatibility with SCXML as a design goal. SCXML treats its datamodel (our context) as a single value with top-level properties for the whole machine. It doesn't account anyhow for "typestates", it also makes "forgetting" unused properties not ergonomic (it's harder to just swap out whole context value).

The overall thing is not impossible but requires some thought, experimentation and new tools/APIs.

[dearlordylord]

Just FYI (knowing that SCXML W3 doesn't suggest that directly), Apache Commons implementation suggest having a context per state https://commons.apache.org/proper/commons-scxml/guide/contexts-evaluators.html