Should effects types in @xstate/store better support async functions as arguments?

[williamrjribeiro]

Hi there! 👋

This code pattern is quite common in my application now:

const store = createStore(
  {
    context: {...},
    on: {
      requestReset: (ctx, _, enqueue) => {
        enqueue.effect(async () => {
            const result = await resetPassword(ctx.username);
            result === true ? store.trigger.resetRequestSucceeded() : store.trigger.resetRequestError(result);
        })
        return { ...ctx, resetInFlight: true }
      }
    }
  }
)

We recently added typescript-eslint to help us increase the codebase quality, and the kind of code above violates the no-misused-promises rule: the function enqueue.effect is not expecting an async function as an argument.

The workarounds are simple enough, but they're quite unappealing.

Therefore, my question: Should effects types in @xstate/store better support async functions as arguments?

Thanks in advance.

[davidkpiano]

I think they can/should, but they'd be typed as Promise<void>. I'd gladly accept a PR for this type improvement.

[williamrjribeiro]

OK, that should be fun. Let's give it a shot.

[Andarist]

Wouldn't it be enough for you to configure the lint rule with checksVoidReturn: false?

[williamrjribeiro]

Technically, yes, but like I said before, that's quite unappealing. Dodging ESLint rules is an anti-pattern that we avoid as much as possible. It really encourages us to learn and write better code. 💪

What's the downside of introducing this specific change to XState Store? 💭

[Andarist]

when you read code like:

enq.effect(async () => {
  await fetch()
})

you might think that we actually do something with this promise, handle errors, or await its result. But that's not true. For the same reason, you can't directly use async functions together with React.useEffect: TS playground

It somewhat feels to me that you want this patch to trick the lint rule it's OK. But that lint rule exists exactly to guard you from misusing async functions in situations like this.

[williamrjribeiro]

I 100% agree with you there. I was surprised to see that XState Store didn't handle async effects at all. It's really a "fire and forget" approach.

It's better to leave the code unchanged, as it will allow strict linters to inform developers about how the library code works.

Would you be willing to change the XState Docs then? The Side Effects section could be improved to provide more detailed explanations and related best practices.

The example code snippet could be changed to something like:

incrementDelayed: (context, event, enqueue) => {
  // You might also use an async function, depending on your linter configuration. The store will treat it as a sync function. 
  enqueue.effect(() => {
    new Promise((resolve) => setTimeout(resolve, 1000))
      .then(() => {
        store.send({ type: 'increment' });
      });
  });
  return context;
},

What do you think?

[davidkpiano]

I was surprised to see that XState Store didn't handle async effects at all.

Side-note, how would you like this to ideally look? What kinds of async effects would you like to handle?

Are you thinking e.g. const result = await store.trigger.createUser(…) or something different?

[williamrjribeiro]

@davidkpiano I'm not sure yet. We recently started using XState Store, so we're still in the process of exploring how it fits in our NextJS app.

So far, we're pleased by the store's reactive nature. We never need to wait for the results of async store operations, as the store updates itself, and the UI re-renders automatically.

[ScottAwesome]

I was surprised to see that XState Store didn't handle async effects at all.

Side-note, how would you like this to ideally look? What kinds of async effects would you like to handle?

Are you thinking e.g. const result = await store.trigger.createUser(…) or something different?

Being able to await a trigger would be extremely useful!

The one thing about @xstate/store is its not self aware reactivity. e.g. there's no transparent way to ensure the order of operations for triggering things, and enqueue.effect I don't believe guarantees order of operations since there's no handling of the function itself.

Though I agree with the parent, the docs are confusing, because you show an async function with enqueue.effect but upon inspection its not even awaited internally, its just executed to the dustbin.

It makes me wonder if enqueue.effect is a good idea long term? At the very least, you should be able to leverage async atoms and return one so that the store at least calls unsubscribe on cleanup.