[React 18] Selective Hydration fails hydration when using context api

[maraisr]

Based on the selective hydration example provided by @gaearon ??

https://codesandbox.io/s/mystifying-haibt-39oed

Look out for 👉

One can see that hydrating html does in fact fail when using Context API — or perhaps that's a red herring? The trees do in fact line up during render, and hydration, there's just an effect that sets state — but that is post hydration??

Could be them related; in anycase — strictly speaking to that code sandbox, what am i doing wrongly?

---

Initially caught when ImportedComponent fails see https://github.com/theKashey/react-imported-component/blob/c290d76623693389a11cc514c92f47efadac47ba/src/ui/ImportedController.tsx#L29

[maraisr]

cc @theKashey

[theKashey]

As I understand - any context update invalidates all dehydrated SuspenseComponents. Not sure is it a feature or a bug, and is there any extra flag on Suspense to control this behavior.

[maraisr]

Perhaps an EventHorizon aka memo we can wrap and all is good. As context update not necessarily altering the tree south a Suspense boundary.

Think really this means any state update until a Suspended hydrated component, will cause things to break — not really about context.

[salazarm]

So its unrelated to context. I setup a more minimal repro here: https://codesandbox.io/s/crimson-frost-y5tz9?file=/src/App.js

So what happens is on initial hydration when the component suspends we don't switch to the fallback, but then later when we re-render App we see the Sidebar component suspended and we do decide to show the fallback then. I think maybe we should skip over dehydrated suspense boundaries during re-render. cc @sebmarkbage @acdlite

[sebmarkbage]

It’s a feature. If something doesn’t update, then sure, it’s unnecessary but we don’t know that. If something does update, then the tree would be inconsistent and perhaps non-sensical. Eg imagine switching selected item and it doesn’t change the selection and then you press the delete button.

Note that this doesn’t (shouldn’t) happen with transitions since it’ll first go back in time and then try to hydrate again. If it suspends, it’s just a transition so it waits to commit until it unsuspends.

It usually isn’t noticeable but becomes noticeable when you use other bad patterns like sync rerenders in a layout effect. They’re common but still bad for perf and should be avoided.

It used to happen less because more things were async but since we made things sync, they happen more now.

The issue with sync updates is that we can’t delay the update or give up consistency. So we have to show the fallback.

However we might throw away the SSR content unnecessarily. It’s tricky because sync updates might rely on legacy things that read mutable state so you can’t necessarily safely do a two pass render. Maybe certain things like updates in passive effects or pseudo-sync things like Default pri, could be made to do two pass.

But in general, the way to avoid it is by using a transition.

[sebmarkbage]

When you don’t use Context, the trick is to use memo or useMemo.

e.g.

useMemo(() => <Suspense…>…</Suspense>)

That way we know it hasn’t changed. Context is brute force because we don’t know if something below reads it.

[theKashey]

If I read correctly - there is no way to keep areas suspended with context updates, many of them can have just "not-UI" nature, like hydration/loading state to power phased code splitting (importForInteractions)

Can I ask to provide more control over this to the user space, as I am more than capable to invalidate my caches and can understand when I need suspended fragment to be hydrated. More of it - probably in this case I need it to be actually "hydrated", ie want hydration process to continue, not destroy existing tree and display fallback.

[sebmarkbage]

The way around it is to not use React for tracking the updates. You can use a subscription (possibly with useSyncExternalStore).

If you want deep advanced control over how parts of a page is hydrated, you’re better off splitting up into multiple roots. Like is already possible. It’s going to interplay with other features in subtle ways anyway that you’ll need to resolve.

[theKashey]

That sounds like a really complication for any existing applications, which can be summarised as “use a self contained state management solution, some of them will work, not low level system primitives”

Multiple roots are falling into the same bucket, as every such root should be wrapped with all required providers with common state or synchronised, or exists outside or React.

For quite a while the overall diffraction was to put more stuff “in”, so asking to put some “out” is not an option as it requires some sort of shotgun surgery for many third party dependencies

[gaearon]

To be clear, you do have a level of control there — updates wrapped in startTransition won't do this.

[sebmarkbage]

The general model here is that code is expected to load relatively quickly and that you eagerly hydrate the whole page on idle.

This makes it so that you typically won’t hit the scenario of hiding existing content. Since you’ll have downloaded everything by the time the user interacts with the page.

The exception is things that update immediately and synchronously without user interaction - which is bad practice for other reasons already.

The other exception when this can become a problem is when you don’t subscribe to the eager hydration model. Eg if you only want to even start downloading the code upon interaction. That’s a very different model than what we’ve designed for, so it requires a different design. That’s the case where I suggest splitting into multiple roots.

Another case if you do clever stuff by inferring that hydration is going on but I think it’s fair that you have to spend some time updating those libraries when the hydration model has drastically changed. It’s likely to break anyway since the assumptions have changed.

In other cases this wouldn’t be an issue.

[theKashey]

‘startTrasition’ will not work as it will delay the state update until it is “possible” - https://codesandbox.io/s/crimson-breeze-17c8n?file=/src/App.js

hydrate the whole page on idle

why would I want to hydrate whole page, when it’s footer might be never viewed by the user, as well as many other elements (SVG) can be kept “dead html” for quite a while.

I was looking forward to hydrate-on-interaction or hydrate-on-scroll, but not on “just hydrate”

[gaearon]

why would I want to hydrate whole page, when it’s footer might be never viewed by the user, as well as many other elements (SVG) can be kept “dead html” for quite a while.

Because there is no reason not to. Since the algorithm is interruptible and each individual component shouldn't stall the thread in isolation, doing it eagerly is not prohibitive. It's just an optimization.