Client render dehydrated Suspense boundaries on document load

[gnoff]

When streaming SSR while hydrating React will wait for Suspense boundaries to be revealed by the SSR stream before attempting to hydrate them. The rationale here is that the Server render is likely further ahead of whatever the client would produce so waiting to let the server stream in the UI is preferable to retrying on the client and possibly delaying how quickly the primary content becomes available. However If the connection closes early (user hits stop for instance) or there is a server error which prevents additional HTML from being delivered to the client this can put React into a broken state where the boundary never resolves nor errors and the hydration never retries that boundary freezing it in it's fallback state.

Once the document has fully loaded we know there is not way any additional Suspense boundaries can arrive. This update changes react-dom on the client to schedule client renders for any unfinished Suspense boundaries upon document loading.

The technique for client rendering a fallback is pretty straight forward. When hydrating a Suspense boundary if the Document is in 'complete' readyState we interpret pending boundaries as fallback boundaries. If the readyState is not 'complete' we register an event to retry the boundary when the DOMContentLoaded event fires.

To test this I needed JSDOM to model readyState. We previously had a temporary implementation of readyState for SSR streaming but I ended up implementing this as a mock of JSDOM that implements a fake readyState that is mutable. It starts off in 'loading' readyState and you can advance it by mutating document.readyState. You can also reset it to 'loading'. It fires events when changing states.

This seems like the least invasive way to get closer-to-real-browser behavior in a way that won't require remembering this subtle detail every time you create a test that asserts Suspense resolution order.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-compiler-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 23, 2024 5:45am

[react-sizebot]

Comparing: 2a9f4c0...a9b45d1

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.68 kB	6.68 kB	=	1.82 kB	1.82 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.12%	509.94 kB	510.55 kB	+0.18%	91.24 kB	91.40 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	=	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.12%	514.88 kB	515.49 kB	+0.18%	91.95 kB	92.11 kB
facebook-www/ReactDOM-prod.classic.js	+0.10%	594.80 kB	595.41 kB	+0.14%	104.96 kB	105.11 kB
facebook-www/ReactDOM-prod.modern.js	+0.10%	585.07 kB	585.68 kB	+0.14%	103.39 kB	103.53 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against 0df3dc3

[sebmarkbage]

Probably not worth the extra complexity in code to do the scanning but the retry callbacks should probably move to the commit phase.

This is fine though if we assume the gc work won’t be much and the callback actually always fires.

[sebmarkbage]

It’s probably fine to rely on this these days but I’m always paranoid of new features. If this is an old browser it would forever leak potentially very large trees.

An alternative to this is to explicitly just remove the same listener when called.

[sebmarkbage]

Whenever we add listeners in the render phase I need to look closer because it’s risky. For example that it won’t ever clean up.

We already do this with the retry but at least that overrides an existing callback which frees the previous one and it automatically frees once the dom node itself is removed.

For every attempt that has to be given up, we end up closing over the whole fiber tree that was attempted that we normally just gc. The clean up mechanism we have as a safety for leaking large trees won’t even kick in because it never commits so there’s no unmount. (This would be fixed by the big refactor idea to split the Fibers into two but unclear if that will ever happen.)

So it’s absolutely critical that this event actually fires and the closure gets cleaned up. However even then it might leak some attempted trees in the meantime which can leak to more gc work too since they now move to older generations.

The ideal would be to either move this whole thing to the commit phase or maybe lazily scan the fiber tree.