re: State machine advent: A safer way to type events and state (11/24) VIEW POST


I have been using enums a lot in the past (not with xstate), but then I switched over to string unions and it feels much better. I wonder if it could somehow be utilized here as well.

export type TLightSwitchState = "inactive" | "active"

export type TLightSwitchEvent = "TOGGLE"

I am not that well versed with TS yet to figure out the next steps. It would be lovely if we could do something like and it would assemble the correct final type for a machine.

interface LightSwitchStateSchema {
  states: States<TLightSwitchState>

It's a cool idea but keep in mind that you also have to use the values to check the current state or to send events. How would you get the light switch event value when doing something like this?

<Switch onChange={() => void send(LIGHT_SWITCH_EVENT.TOGGLE)} />

If you are interested in reducing boilerplate, check out this experimental builder for XState github.com/iliasbhal/xstate-builder and submit machines for the author to look at in this issue.


Another way is to create a plain JavaScript object from an array using .reduce() which allows you to define each string only once.

].reduce((obj, item) => {
  obj[item] = item;
  return obj;
}, {});

// then use it like this: LIGHT_SWITCH_EVENT.TOGGLE

I'll stick to enums as I think they are much easier to read.


The interesting project although it might end up with quite complicated API to cover all cases that XState supports.

As for unions, usually, I do the following when it's hard to have correctly typed one end. It will correctly type-check like that without the need for verbose enum.

export const makeEvent = (name: TLightSwitchEvent) => name

// in the component


Not sure why send is not currently typed in this regard. It should ideally be able to infer from the machine itself.

And matches are obvious bigger nut to crack with nesting. I am not sure if TS allows for it dynamically.

code of conduct - report abuse