[React 19] Disabling prerendering siblings of suspended components breaking common pattern

[ehellman]

Summary

I'm creating this issue to continue the discussion that spawned in the already merged PR (#26380)

Several community members have raised concerns about this change and it has gained traction on both X and Reddit as well, I think it is important to prioritize this discussion as it can be a dealbreaker whether or not a project will upgrade to React 19 at all of this is not addressed.

The problem

This change causes sibling components of suspended components to not prerender, meaning that it will cause performance problems when using a very common pattern where you do data fetching near to where the data is actually used. It makes requests that would before be performed in parallel due to prerendering triggering them, into waterfall requests instead. Here's screenshots from @matiasngf and part of their description from the pull request comment:

First, we recorded the current approach; it takes about 2.5 seconds to load the .glb models:

Then, we installed the canary version of react; Same .glb models, takes about 3.5 seconds to load:

I included the above example in the issue body because it is a great illustration of the problem. Their comment also include links to both their current site that doesn't have the problem and also a version of their site with an updated React with the problem present.

Discussions around potential fixes

There are several ways to approach this, but I think @matiasperz were spot on when suggesting that this entire change be opt-in. The changed logic seems like the part that should be opt-in, and the default behavior should be the way things worked before the change.

Something along the lines of: strategy={"parallel" | "sequential"} where it is clear how suspended components will behave.

Conclusion

While not exactly a breaking change in the literal sense, I would personally consider this a breaking change and worse, one that it is not possible to easily migrate away from without changing the entire data fetching pattern for your application. The other option being just eating the performance loss but no one is realistically going to do that.

Moving data fetching up is not a good recommendation, since it goes against an extremely common and well-liked pattern in the community and the great thing about React has always been that we can choose our own patterns and develop amazing applications in several different ways. But changes like this, if you cannot opt-out of them (or in this case opt-in, because considering the effects it will have the sensible default should be the previous behavior) would break this very fundamental value of React.

Let's please continue to discuss this to find a good path forward.

[rickhanlonii]

Thanks for submitting, let's use this issue to track the feedback for the suspense changes in 19.

[neil-morrison44]

Just to aid anyone looking for further discussion, there's a lot of great points being made by 0xca0a (@drcmda here) over on Twitter which I expect could gel with a lot of how us were viewing <Suspense> (especially if we've used react-three-fiber).

Particularly this & this about viewing Suspense as async task management (rather than strictly fetch).

Personally I've got code that Suspends when doing fully local async things like:

• decoding binary data (and doing async blob stuff with it)
• rendering to offscreen canvases
• reading metadata from in-browser zip files
• accessing IndexedDB, etc

which I was looking forward to migrating to use with React 19 but this change'll cause to waterfall without an opt in / out. Or breaking a nice separation of concerns by doing outside of where it gets (often conditionally) used.

---

I'll also restate my point from the PR comments that React really should have performance regression tests being run, instead of just bundle size. Since, assuming they were representative of React apps deployed in the wild, this would have been seen as a big change when it was proposed.

[sophiebits]

update fyi — just tweeted https://x.com/sophiebits/status/1801663976973209620

good news re Suspense, just met w/ @/rickhanlonii @/en_JS @/acdlite * we care a lot about SPAs, team misjudged how many people rely on this today * still recommend preloading but recognize not always practical * we plan to hold the 19.0 release until we find a good fix

more to come

[ckifer]

Thank you and kudos to the team for the creation of this issue, listening to the concerns of the community, and the updates on this thread. Looking forward to the fix/discussions moving forward 🙌🏼

[LucaColonnello]

Just want to say, this is the perfect example of owning it! Thanks for considering the feedback of many!

[Nick-Lucas]

Initial explanation hits the nail on the head. Thank you for returning this to consideration!

If we can have a boundary-level opt-in or opt-out then I'm personally excited to be able to pick the mode based on the properties of the page/region I'm rendering. Sometimes prefetching is just the best choice, and then it makes total sense to use "sequential" and benefit from further performance gains.

So many great features in react can be adopted gradually and contextually, so this would be another great tool in that box to take a working app and enhance it

[drcmda]

Thank you React team, for listening!

Maybe this all stems from suspense being referred to as "data fetching" in the React docs, water falling after all is usually a browser concern. Vue is spot on with their docs, this is what i would wish for React as well:

It would go a long way if suspense could be understood as compositional management of async task runners, independent of SSR, DOM, routes, fetch. It would make it much clearer why it cannot water fall (by default at least). Suspense is the only means to enable libraries and components to have true interoperability. I have wondered for years how it is not celebrated and used all over, and i think it might be communication.

Even the simplest constructs it enables are amazing. The following would have been impossible in React 15 for instance:

<Center>
  <SomeUIComponent />
  <SomeOtherUIComponent />  
</Center>

Because how could <Center> know if a child is async or has finished its task runners, be it fetch, wasm, workers et al. Thanks to suspense it can safely assume that all children are completed come useLayoutEffect or useEffect, and act upon the results.

I wish i could some day show you how pmndrs has built eco systems on top of it. It seems forms-React has only just noticed it can fetch in-place and access results without useEffect + setState, but there is so much more to suspense than that.

[krispya]

It has already been said very well how we have many async tasks that have nothing to do with data fetching in the pmndrs ecosystem. I just want to add that async being built into Javascript is one of its major strengths and while we are encountering this friction with our 3D libraries currently, it will not be limited to that. For example, any AI library will need async for everything it does, from setting up its program with the GPU to sending and receiving messages. React 19 needs to handle bundles of async tasks generally or it will not be compatible with general JS features going forward.

[revskill10]

Thank you React team, for listening!

Maybe this all stems from suspense being referred to as "data fetching" in the React docs, water falling after all is usually a browser concern. Vue is spot on with their docs, this is what i would wish for React as well:

It would go a long way if suspense could be understood as compositional management of async task runners, independent of SSR, DOM, routes, fetch. It would make it much clearer why it cannot water fall (by default at least). Suspense is the only means to enable libraries and components to have true interoperability. I have wondered for years how it is not celebrated and used all over, and i think it might be communication.

Even the simplest constructs it enables are amazing. The following would have been impossible in React 15 for instance:

<Center>
  <SomeUIComponent />
  <SomeOtherUIComponent />  
</Center>

Because how could <Center> know if a child is async or has finished its task runners, be it fetch, wasm, workers et al. Thanks to suspense it can safely assume that all children are completed come useLayoutEffect or useEffect, and act upon the results.

I wish i could some day show you how pmndrs has built eco systems on top of it. It seems forms-React has only just noticed it can fetch in-place and access results without useEffect + setState, but there is so much more to suspense than that.

Sorry but i'm a bit confused on this. Generally, if i understand your point, there should be 2 kinds of Suspense. The headless Suspense and the Rendering Suspense, which acts differently.

Using Suspense currently promotes the use of render-then-fetch strategy, which is bad on slow-network condition.

[pkellner]

Any update on when this issue may be resolved and how it will impact the R19 release schedule?

[eps1lon]

Any update on when this issue may be resolved and how it will impact the R19 release schedule?

https://github.com/facebook/react/issues/29898#issuecomment-2168472355 is still the latest.

[alexreardon]

Thanks so much for your hard work in this difficult domain!

Out of interest, I have explored what a <Suspense> algorithm would look like if all thrown promises were resolved before trying to re-render ('wait for pending').

→ Write up

TLDR: 'Wait for pending' is an interesting variation of the react@18 ("parallel") and react@19 (alpha) ("serial") <Suspense> algorithms. For flat async trees, 'wait for pending' allows for fast calling of render functions, and minimal re-renders. For trees with nested async components, child async components will have their initial render called slower than the react@18 algorithm.

I am not suggesting that 'wait for pending' is used, but it is interesting and might spark other ideas. My thinking right now is that providing an option for <Suspense> (eg "serial" or "parallel") would be a great path forward.

[IVLIU]

I've reviewed the original PR. Regarding the issue with use, could we maintain a ThenableList on the Suspense fiber? We would always throw the first unresolved promise until it is resolved, then look for the next one until we reach null.

[IVLIU]

or like this

<Suspense>
  {(isSuspend) => (
    <></>
  )}
</Suspense>

even though I really hate it, I also don't want to do it this way.

[ehellman]

@rickhanlonii @sophiebits Thanks for picking this up. It's a bit sad that this issue got a lot of traction on Twitter with many interesting discussions but hardly anyone of these people have contributed to the discussion here, where the code is, where the change will take place and where people can search for these discussions in the future to ensure we don't repeat ourselves or to learn about previous decisions.

That said, it would've been a much bigger problem if this was a more complex issue where it felt uncertain what the end goal should be. Right now it feels like both the part of the community that reacted to this change and the team are both clear on what the end goal is and how we want this feature to behave. It's just worth to think about in the future, ensuring that we bring important information back close to the code.