Dealing with components streaming in later, updates before hydration

[thomasballinger]

I'm still getting adjusted to the new world where suspense boundaries cause React subtrees to stream in and hydrate later. In this world there's no definitive "hydration of the entire tree has finished," yeah?

I'm seeing updating the value in a context provider after that provider component has hydrated, but before all of the subtrees have streamed in and hydrated (perhaps because of a useSuspenseQuery() call in them with an implicit or explicit suspense boundary above) cause this error in React 18.3.1.

This Suspense boundary received an update before it finished hydrating.

This makes me want to avoid using a context to update values at all. Does that seem like a good idea? Like React Query, never modifying a context and using external state to update the components (once they have hydrated) instead of context, because of this error? If I do this, will I be stuck creating my own versions of third party Provider components which won't abide by this rule?

This fallback to client-side rendering seems potentially useful, but any ancestor context updating isn't selective enough.

[thomasballinger]

After chatting with folks knowledgeable here and some thought:

It's too bad that updating a React Context isn't more granular because it's causing false positives here, but the reality is that a change should cause the streamed-in component to default to client-side rendering!

This error should be gone after facebook/react#25692, but I haven't tested with React 19 to know for sure.

facebook/react#24959 has some relevant discussion, this is an old problem; I'm just hitting it more because I'm using suspense boundaries more with TanStack Start.

I think it's still interesting to think about preventing this from happening: it means the SSR-d content is being thrown away, and if any context update will cause this then it's a bit of a bummer! So I do think I'll tend toward avoiding updating React Contexts if I can avoid it with a user interaction like turning on dark mode with a switch. If I were writing e.g. an auth library today, I think I'd try to avoid these context updates, but for the dozens of Context providers folks end up with in a production app today it's plausible some of them will update a context before hydration has finished.