loading...

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

TOP OF THREAD FULL DISCUSSION
re: 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 cou...
 

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.

const LIGHT_SWITCH_EVENT = [
  'TOGGLE',
  'SOME_OTHER_EVENT',
].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

send(makeEvent('TOGGLE'))

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