What's the best way to stop client-side hydration on a part of the document?

[wardpeet]

With the new createRoot API, React's parser can await rendering on a suspense boundary and keep the HTML intact. With Server-side components, we go into a new era where you only hydrate client-side components.

Can we already do it without Server-Side Components where we don't hydrate specific pieces of a React app? Instead, we only render it on client-side navigations? The approach that comes to mind is to add a Suspense boundary that never resolves. This allows us to reduce the initial requested data and exclude pieces out of the initial js bundle.

Any better solutions, or should we wait for server side components?

Here is an example:
A page contains many SVGs that are defined as JSX. These SVGs are unnecessary to be included in the initial js load as they are pure static (no effects, state, ...). Same goes for things like Markdown where we don't have to include the data as part of the page.

[sebmarkbage]

Even if you suspend a boundary for ever, if you have a synchronous update that flows new props into the component, it’ll delete the content and force client rendering instead to ensure it can be updated.

You could still ensure that it’s always wrapped in a suspense boundary that has its props memoized. But if a Context above it synchronously updates we have to hydrate it to see if there are any Contexts inside it. We don’t know that before we open up the code so to speak.

Even if that worked you’d still be downloading the code.

The real solution is Server Components since it’ll have a different type of Server Context that can’t be updated by the client and the way props flow they’re not flowing in from Client Components so they can’t be updated.

At the same time, hydration happens at a low priority so if it’s not interrupting anything does it matter? It’d mostly matter for maximum memory usage which could eventually turn into an issue but it’s not direct.

So it might not hurt to just let React do it, and at the same time if you do get a synchronous Context update you’d do it then anyway. In that case it probably would’ve been better to warm it up than to do it lazily.

So I’d probably avoid this strategy pre-server components.

If the SVGs are truly large then it might make more sense to have them as external source images or even some rasterized format.

If they’re a few paths the overhead in React is small enough not to matter.