Support state and event as enum value about xstate-tools HOT 4 OPEN

I think this is necessary, too. We can only communicate with the machine through events in XState, but the event type is currently using as string type. I tend to use enum for convenience of management because the type of event can be used in both machines and communication. Think about when you just want to rename an event type for readability. Enum allows you to find and change where you used the event type. Otherwise, you must manually find and change the event type string.

When saving VSCode's XState Visual Editor, the editor changes the modified content in the code. However, actions created in line are excluded. Considering this method of operation, I think we can add this function by excluding keys entered by Computed property names from the code change.

from xstate-tools.

There are some unanswered questions with supporting a feature like this:

• What if an event type is changed in the editor? Should Typegen try to look for the proper enum or use a string?
• What if a new event type is added? Should Typegen try to add a new enum, use a string, or change the existing enum if that was the only place it was used?
• If the enum is changed, what if the enum is used in other places other than the machine? What should be done?

There's a lot of ambiguity that arises when trying to make Typegen "read your mind", as the number of potential ways a machine can be authored grow.

from xstate-tools.

I checked the link after leaving a comment. If I used Typegen, I was able to obtain the type estimation more comfortably and accurately than manually entering the type. I also overlooked that the editor can change the event name and state name. Unlike my previous comment, I think it's not a simple task.

I didn't use Typegen, but when I applied Typegen as shown in the link, I thought I didn't have to use enum. If you haven't used it, I recommend that you try it. @nicholas570

from xstate-tools.

@lowfront thanks, I'll try it 😉

from xstate-tools.