Conversation
🦋 Changeset detectedLatest commit: b00e065 The changes in this PR will be included in the next version bump. This PR includes changesets to release 8 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Hey, I'm starting to use xstate on backend and I'm recently discovered TypeStates. I was looking for some way to define a concrete state of the context on an determined state point... Seeing this PR, I wonder what is the new way to do it? |
There is no new way to do it. What is being removed in this PR wasn't quite type-safe and we have to think about other ways to achieve this, this time in a type-safe manner. |
Co-authored-by: Mateusz Burzyński <mateuszburzynski@gmail.com>
Co-authored-by: Mateusz Burzyński <mateuszburzynski@gmail.com>
CodeSee Review Map:Review in an interactive map View more CodeSee Maps Legend |
Like @Andarist said, we're currently figuring it out. One idea is to use a design-by-contract approach so that you can guarantee that certain conditions hold in a state: // idea
states: {
loading: {
invoke: {
src: 'loadUser',
onDone: { target: 'loaded', actions: assign({ user: (_, e) => e.data }) }
}
},
loaded: {
// precondition - assert this is true whenever entering this state
pre: (ctx) => !!ctx.user // in this state, the `user` should always exist
// ...
}
}Then, a typegen can derive that in |

This PR removes
Typestatetypings from XState core.