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

[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

[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.

[LucaColonnello]

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

[rickhanlonii]

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

[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.

[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 🙌🏼

[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.

[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.

[mattbolt]

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.

I've spent hours pouring over online commentary on this topic and I'm struggling to find what the final consensus was for resolving this, and what kind of timeframe we have until React 19 is stable (as most places are singularly blaming this topic for the hold up).

Is there any updates and indications when it will be resolved?

[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

[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.

[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?

#29898 (comment) is still the latest.

[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.