XState v6 roadmap

[davidkpiano]

This is a placeholder discussion for XState v6 ideas and future plans.

Roadmap

• Deprecate types in machine config
• Forbid partial assignment in assign(…)
  • Partial assignment can easily bypass type-checking to lead to invalid states, and is not compatible with ideas for typestates
• Use machine.withInput(…) instead of createActor(machine, { input })
  • This simplifies the types and gives more explicit feedback to developers when input is required. Current type error message is cryptic

[CodingDive]

Tbh, XState v5 is so good, it could stay on this version forever and I'd be happy!

Nonetheless, here are my wishes for a new version.

Could guards somehow narrow the type of properties in the context of actions? I'd imagine this to be quite tricky, but maybe exposing another type helper on top of the existing ones (and, or) like "exists".

guards: {
  hasUserActor: ({ context }) => exists({userRef: context.userRef)}, // usually I'll have Boolean(context.userRef) here 
}
...
{ 
  guard: 'hasUserActor`,
  actions: sendTo(({context}) => context.userRef!, // Here we always need to use the exclamation mark

Would be awesome if TypeScript knew that the userRef certainly exists when the action is called.

Another type related thing is full type support for enqueueActions defined in the actions of setup as outlined in this issue #4820?
As @Andarist wrote in the issue, it seems to be a current limitation of TypeScript, but I also know that he is involved in the language design.

[steveadams]

I love this idea.

Something similar I'd like to achieve is defining valid contexts pertaining to different states. That should be able to solve this problem in many cases (though not all).

For example, I might say in stateX I should see a context containing a userRef, but in stateY, I never should. Therefor all contexts assigned for stateX should always contain a userRef, and I should never need to assert that it's there.

[CodingDive]

You are talking about typestates that David mentioned! 🙌

[davidkpiano]

Thanks for the kind words! I like your suggestion and have been thinking about it for a while.

One huge idea I had for v4 is to enable more idiomatic coding, to take advantage of natural type narrowing in TypeScript. The most natural way to code your example is:

on: {
  someEvent: ({ context }, enq) => {
    if (context.userRef) {
      enq.sendTo(context.userRef, { type: 'someEvent' })
    }
    
    return 'nextState'
  }
}

For typestates, we were thinking of introducing invariant properties on states, so you can be certain that the context has a certain shape while in that state:

someState: {
  invariant: (context): context is { user: User } => !!context.user,
  on: {
    someEvent: ({ context }) => {
      context.user; // defined
    }
  }
}

[with-heart]

For typestates, we were thinking of introducing invariant properties on states, so you can be certain that the context has a certain shape while in that state:

someState: {

  invariant: (context): context is { user: User } => !!context.user,

  on: {

    someEvent: ({ context }) => {

      context.user; // defined

    }

  }

}

What happens if invariant returns false?

[davidkpiano]

Then an error is thrown, since an invariant specifies something that should never happen

[bzbetty]

Couple of times I've wanted multiple guards.

eg

  guards: ['isValid, 'hasUserActor`]

where all would have to return true

can easily make a helper to do this, but would be nice.

Also feel like multi invoke + onDone could be anice addition

 loading: {
    invoke: [
       {src: ...},
       {src: ...},
       {src: ...},
    ],
    onDone: () => {}
 }

[CodingDive]

Multiple guards have the built-in helper and that you can import from xstate and use like this

guard: and(['isValid, 'hasUserActor'])

[davidkpiano]

I would also like to support a more natural API like this in v6:

on: {
  someEvent: ({ context, event, check }) => {
    if (check('isValid') && check('hasUserActor')) {
      return { value: 'nextState' };
    }
    // else, undefined
  }
}

This would still work with state.can(…) since if the transition function returns undefined, then state.can(…) would return false.

[tamlyn]

Better server-side support please:

1. some kind of persistence hook that triggers after a state transition has completed and blocks before entering the next state. I want to run each state transition in its own DB transaction, and commit after each successful transition. I've tried doing it with subscribe, but the trouble is the state machine keeps running in parallel with the database operations which leads to race conditions.
2. some kind of settled hook which fires when the actor is waiting for an external event from, i.e. from actor.send. In a serverless environment, I need to know when the actor still has more work to do, or when it's safe to persist its state and freeze the runtime. I can work around this by using tags on the states that should be considered settled, but this is error prone.
3. some way to pass a new database transaction into a running actor. As I mentioned, I want to run each state transition in its own DB transaction. This means each invoked child actor needs to use the "current transaction". It would be nice to have a way to pass this in somehow, though I get that it may be hard to square that with the principle that actor state is entirely encapsulated. I can work around it with a shared mutable object (in a React ref style) but it feels hacky.
4. some way to have custom implementations of "wait" states. In a serverless environment, setTimeout is no good. I want my wait states to send a delayed message to a queue or something then wake up my state machine when the times comes.

Points 2 and 3 have workarounds, but point 1 is currently preventing me from using XState which makes me sad.

[azasorin-rss]

I'm not sure if this applies for your specific situation, but for point 1, I was able to avoid race conditions with a task queue as per @davidkpiano's suggestion.

#4895

[tamlyn]

Thanks. Yes, I used the task queue which helps ensure that state changes are handled in sequence. But it's not enough. For example:

1. Actor transitions from state1 to state2
2. next hook fires and adds item to task queue to save state2
3. meanwhile state2 invokes a child actor which does some side effects
4. persisting state2 to DB fails for some reason

Now we're in an inconsistent state. The DB says we're in state1 but actually state2 side effects have already happened.