[v5] Remove Typestate

[davidkpiano]

This PR removes Typestate typings from XState core.

[changeset-bot]

🦋 Changeset detected

Latest commit: b00e065

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 8 packages

Name	Type
xstate	Major
@xstate/graph	Major
@xstate/immer	Major
@xstate/inspect	Major
@xstate/react	Major
@xstate/svelte	Major
@xstate/test	Major
@xstate/vue	Major

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

[tonivj5]

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?

[Andarist]

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.

[ghost]

CodeSee Review Map:

Review in an interactive map

View more CodeSee Maps

Legend

[davidkpiano]

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?

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 loaded, ctx.user will exist.