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.
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?
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.
constLIGHT_SWITCH_EVENT=['TOGGLE','SOME_OTHER_EVENT',].reduce((obj,item)=>{obj[item]=item;returnobj;},{});// 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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
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.
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?
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.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.
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.