SSR: rehydration broken for React.Context

[AndrewSB]

On initial renders, rehydration doesn't seem propagate React.Context correctly down the component chain.

To Reproduce

Here's a minimal repro: https://github.com/AndrewSB/reduced-context-bug
To see the bug:
Load the page with the window less than 800

Expected behavior

The page should show "Compact"

Actual behavior

The page shows "Normal"

Screenshots

See video in README of linked repo

System information

• OS: macOS
• Browser (if applies) repros in chrome, safari
• Version of Next.js: 9.3.6

[mohsen1]

This probably has to do with how react-use that you're using detects server/client environment:

https://github.com/streamich/react-use/blob/1c7a000735ef05c7391de8078cdfe9ca87d877ec/src/util.ts#L1

[AndrewSB]

that makes sense. What might be a better way to handle this kind of server/client detection?

[zackdotcomputer]

I think you have to not treat Infinity (which is what react-use's useWindow hook returns if it's called as part of SSR) as if it has meaning for your render. Doing so sets you up for a disconnect between the server-rendered HTML (which rendered as if the page were infinitely wide) and the client-rendered HTML (which renders with the proper page width), which is actually what is causing your error.

(If you console.log(displayContext); in your Child component, you can see that the react context is, in fact, passing the right value to the component. The error is that component generates an error on the client-side when it tries to attach to the server-rendered DOM.)

To eliminate that disconnect between server-render and client-dom, you can do one of two things:

1. You can remove any elements that depend on client-only variables from the server-side render. If you're using React Context, this is the much easier route. I fixed the index.tsx in your repro project to do that and posted it in this gist.

2. You can hold off figuring out the new values of any client-only variables until after the components in question mount. This is a little more complex in this case, because it requires introducing both a useState and a useEffect hook to work properly. That fix is at this gist.

[AndrewSB]

I really appreciate the explanation zack, thanks a bunch for taking the time to teach me something!

I'm going to test approach 2, since it means I need to only make the change in the parent and not in the multiple consumers.

---

As a follow up: is it possible for the server to consume the viewport width per-request, so there isn't that disconnect between the server rendered HTML and what the client renders? I imagine each page is SSR'd per build (not per request), but is there a way to either

Have two variants of the SSR'd page be created for widths > 800 & widths <= 800, and then accept the viewport width as a request param and choosing the right prebuilt bundle to send down
SSR on each page request, taking in the width & injecting it into the component (probably through a different hook that doesn't depend on window being defined), so what's initially sent down is correct unless there's been a window resize after the request was made?
This seems like something that people building on this stack would do frequently -- so the initial payload from the server looks as close to correct as possible, but I'm pretty new to writing for the web, so excuse my oversimplified understanding of how this works 🥴

[zackdotcomputer]

No problem @AndrewSB - I'm just having a good time in these discussions!

If you're going to be hosting your site using the built-in next server, then you could definitely do what you're describing using the getServerSideProps function on your page - that's documented here. Since the context parameter includes the query, you could read any query string value off of that and use it to set a prop with the initial viewport size for your server-side render. (This would, though, not be possible if you were planning to use next export to make a static-file version of your site for a service like netlify.)

I think it's worth asking, though, whether that work will be worth it? While there are real benefits to SSRing the perfect version, they are finite. (Put another way, for most sites SSR is an optimization, not a requirement.)

I don't know your app's render profile, so I can't know how worthwhile it is for you, but most sites I've worked on see a difference of a couple hundred milliseconds at most between "perfect SSR" vs "SSR the most common or SEO-friendly version, and switch to the right version client-side with CSS and some useEffect hooks". If that's true for your site too, I suspect users will forgive you a few hundred ms and you can get a day or so of coding back to use on other things.

[AndrewSB]

Hmm, that makes sense. Maybe I'm over engineering a little. I guess not having the perfect SSR sent down for the initial render is fine for my use case