Bug: useTransition and uSES do not work together, uT is not resilient to amount-of-render

[drcmda]

React version: 18.2.0

Steps To Reproduce

We learn that components should not rely on render. But useTransition does seem to rely on it. If we wrap a set into a useTransition:

const [pending, start] = useTransition()
...
start(() => set("foo"))

everything that now suspends because of it is marked as a transition, it will not go into suspense fallback but instead pending will be true. ✅

But if the suspending component, for whatever reason, happens to render again while still in suspense, giving react the same promise that it already has, then it will unpend because that render wasn't marked a transition. ❌

This at least happens when state managers are built on uSES.

Link to code example:

https://codesandbox.io/s/cool-fast-pcz6bv?file=/src/App.js

The current behavior

1. ❌ Fallback, loading...
2. ⚛️ Content
3. ❌ Fallback, loading...
4. ⚛️ Content

In that sandbox it:

1. suspends, it correctly goes into suspense fallback
2. unsuspends, it correctly shows the content
3. suspends again but wrapped into startTransition, it should not go into fallback but pend, but because the suspending component double renders for whatever reason it throws it's promise again towards react, but nothing marked it a transition this time, so the pending state disappears and it goes back into fallback

The expected behavior

1. ❌ Fallback, loading...
2. ⚛️ Content
3. ⚛️ Content
   ✅ Pending ...
4. ⚛️ Content

startTransition should mark the component that suspended a transition as long as it suspends.

btw, @dai-shi has an extension that lets us use zustand without uSES, it does not happen then: https://codesandbox.io/s/suspicious-hooks-hdvxhl?file=/src/App.js

[dai-shi]

I'm not sure if it's described well in react-18 WG discussions (I think there was a tweet about it from Seb.), but the "Sync" is important. It's not useExternalStore. So, it's not a bug per se. It's a designed limitation.

[alexeyraspopov]

I hit the same behavior and it was far from obvious in my case, because uSES wasn't the one that supposed to be triggering suspense. I created this sandbox https://codesandbox.io/s/upbeat-flower-2gnhm6 to show that the shim implementation (use-sync-external-store itself, before it got rerouted to the React hook implementation) didn't have this behavior and was working in the way I as a user would expect: when suspending render is triggered via useTransition, I can use pending flag instead of suspense boundary for UI feedback.

Screen.Recording.2023-06-19.at.11.37.48.mov

[markerikson]

I'll tag in a related React-Redux issue:

• Performance of useSyncExternalStore and React transitions reduxjs/react-redux#2086

[github-actions]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[alexeyraspopov]

Bump. There was no patch for it and we are yet to discover if v19 fixes the issue.

[alexeyraspopov]

I can confirm that this bug is still present in React 19.0.0-beta-94eed63c49-20240425. I created a repo for reproduction (since my old codesandbox disappeared): https://github.com/alexeyraspopov/react-beta-bugs. Here's the video as well. Disregard the first text being always gray, there's another bug I'll report separately. Should I also create a separate ticket for v19 behavior? @eps1lon

Screen.Recording.2024-04-26.at.08.16.37.mov