Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[React 19] Suspense fallback shows for too long compared to v18 #31697

Closed
MichaelB-99 opened this issue Dec 7, 2024 · 3 comments
Closed

[React 19] Suspense fallback shows for too long compared to v18 #31697

MichaelB-99 opened this issue Dec 7, 2024 · 3 comments
Labels

Comments

@MichaelB-99
Copy link

Summary

In React 19, a Suspense fallback always seems to show for a minimum of a few hundred ms even after a promise has resolved.

I'm unsure if this is a bug, or expected behaviour with the changes to Suspense in React 19, but I noticed this when trying out the 19 beta a few months ago on an app that makes use of Suspense a lot (Relay) and it felt as if the app was being throttled to use 4g due to the delay in the fallback being hidden and the children rendered even after the network request had finished. This was especially perceptible when loading a query on user action, e.g hover.

Reproduction

See the videos and links below for a minimal reproduction. Note how in 18, the fallback is barely a flicker, whereas in 19 the fallback is visible for a few hundred ms.

React 19 Codesandbox
React 18 Codesandbox

React 18.2.0 (expected behaviour)

react-18-suspense.mov

React 19.0

react-19-suspense.mov
@martinhath
Copy link

I immediately hit this too when trying v19. In my case it was using jotai atoms containing a Promise, but found that it also applies when useing a value that's Promise.resolve()d.

#26803 seems to be related. Weird that this is not communicated at all in the changelog or in the upgrade guide?

@eps1lon
Copy link
Collaborator

eps1lon commented Dec 9, 2024

When we show a fallback, we will throttle the display of the resolved data to avoid layout thrashing. This was an oversight in the changelog. The throttling was always in place but we just expanded it to more cases in 19.

It was mostly changed in #26611 and #26803

@MichaelB-99
Copy link
Author

Thanks for the clarification. This had been bugging me since I couldn't find any info about it 😊.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants