[Feature] @xstate/react: support React's transition API

[bsunderhus]

React's useTransition hook and startTransition method allow's a state change to be declared as a transition. It would be nice if @xstate/react hooks could support such feature without introducing tearing

Here's a minimalistic example that I forked from https://github.com/InterBolt/tearable-dots and included a battery test for @xstate/react and also battery test for a custom implementation of the hooks but supporting transitions.

At the moment @xstate/react does not support transitions but it also doesn't introduce tearing (as it's using useSyncExternalStore under the hood). A migration to useState + useEffect instead of useSynsExternalStore, would allow supporting the Transition API without causing tearing

[Andarist]

It's not possible to support today what you are asking for because our hooks also return a reference to actorRef, like here:

xstate/packages/xstate-react/src/useActor.ts

Line 66 in 9a8f11e

return [actorSnapshot, actorRef.send, actorRef];

This alone means that we can't migrate this hook to useState+useEffect (at least not without losing some functionality) without introducing tearing.

Similarly, useActorRef would have to go away (or not to be used by users) to avoid tearing problems.

[bsunderhus]

On the unsafeChangeHandle method here:

https://github.com/bsunderhus/tearable-dots/blob/9c1646143b91d51cec2b7e5e37349b849bf2bc53/src/strategies/custom_xstate_react.tsx#L42-L47

I'm accessing the actorRef and modifying the context in a way that should cause tearing, but it's still not happening as I'm consuming the state previous to the tearing happening (similar to what getSnapshot() does on a external store sync), am I missing something here?!

[bsunderhus]

This is only valid for modifications that happen from an event that will immediately cause a transition.
On the case of asynchronous transitions there's not much to be done (but I'm not sure if there would be any tearing either, I'd have to research more)

[Andarist]

The problem can be surfaced by consuming the actorRef elsewhere. Tearing can happen when you consume the same external data source in multiple places when each is coordinated outside of React. That's why I'm saying that returning actorRef makes it impossible~ to avoid tearing. Since we return it, we allow other consumers that won't sync through the returned snapshot (and thus through React's own scheduling). Any other piece of code is free to use that returned actorRef, subscribe to it and thus introduce tearing.

[bsunderhus]

Gotcha, it makes total sense, since there's no way at the moment to force the user to always sync through the snapshot they can introduce any alternative subscription and cause the Tearing.

Still it would be nice to have an alternative that would allow to consume state with the transition API. I guess having this + the ref would be too problematic and user would have to be aware of this problem to ensure no tearing is happening!

Thanks for the explanation @Andarist!