Replies: 1 comment 4 replies
-
|
IIRC, our VS Code extension can currently raise warnings about invalid state names. At the moment, we can't provide more than that but we are actively looking for improvements in this area. The upcoming TS 5.3 (scheduled to be released in November) might also allow us to do some new neat things and we'll definitely be looking for improvements that it might unlock here. |
Beta Was this translation helpful? Give feedback.
-
|
Any news? |
Beta Was this translation helpful? Give feedback.
-
|
Yes! State names are type-safe if you use |
Beta Was this translation helpful? Give feedback.
-
|
Edit: somehow TS suddenly started working. However, my machine invokes another one as actor. How can I get matches to accept the states of both machines as param? I tried both obj and dot-string syntac, but it really only accepts the state names of the parent machine. Thats very cool! But I'm not sure how? Seems like the type object has no Is it the Also: |
Beta Was this translation helpful? Give feedback.
-
|
@davidkpiano I made a new discussion to keep stuff clean and improve future referencing: #5296 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm using xstate v5, havent used any prior versions. It's extremely frustrating that the names of a state are not typesafe.
Consider this code:
I can start at a state that doesn't exist and transition to states that don't exist.
I've tried every possibly way to ensure strongly typed state names like:
None of that works. I even resorted to doing:
This is good, but then the carts at stately.ai don't work anymore with that pattern.
I mean, is this by design? And is there anyway around this?
It's too easy to make mistakes with state names in a large state machine when refactoring
Beta Was this translation helpful? Give feedback.
All reactions