-
Notifications
You must be signed in to change notification settings - Fork 46.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
React 18: Non-recoverable hydration mismatch if mismatch occurs in the same boundary as main script #22833
Comments
Yeah thats why we think this is a reasonable fallback
It shouldn't be a problem, the overhead seems low? cc @sebmarkbage |
I think this is probably a bug. At the root, we should probably client render or use the old strategy of patching up. The issue is that we don't know how many children belong to the root unless we insert comments. The issue with Suspense boundaries is that they add to the semantics of the loading state so might see more than you should. We also have a concept of "backup boundaries" which are more suitable for this kind of thing. We haven't exposed them in the MVP though because we haven't finalized the API (avoidThisFallback). In general they're useful for enabling more fine grained partial hydration. The reason they necessary is because:
However, that just explains why we have backup boundaries for deeper in the tree. They can also be used for any general purpose error handling on the server because they can render a temporary state while the client renders instead. You probably shouldn't need that on the server though. It's probably better that you can have an error boundaries deal with it server side in that case. So that still leaves the case of client hydration mismatch. |
The issue here is actually because we're hydrating into
Thinking through how to fix this |
I believe this is related to the issues people are seeing around hydration when 3rd party browser extension modifies the DOM. Here is a reproduction case: https://github.com/jacob-ebey/react-18-hydration-bug |
@eps1lon can you confirm #24523 fixes this issue. I tested it here https://codesandbox.io/s/react-18-hydration-mismatch-in-document-fixed-24523-9n6zos?file=/package.json and believe it does. |
Sweet! Hydration errors are expected. But now we can at least recover. |
This is out in 18.2. |
Half a year has passed, and the problem still exists |
+1 |
Still having this issue in 18.2. |
Hey all 👋 I work at Cypress and we have been trying to track down this on our end as well. Would be happy to assist on providing examples or work together on a fix for this. |
React version: 18.0.0-rc.1-next-cb1e7b1c6-20220303
Steps To Reproduce
<script />
for main entrypointLink to code example: https://codesandbox.io/s/react-18-hydration-mismatch-in-document-6buos (based on https://codesandbox.io/s/kind-sammet-j56ro?file=/server/render.js:1054-1614 from reactwg/react-18#22)
The original issue was caused by a wrong usage of the Remix starter template:
The hydration mismatch happened due to a mismatch of
process.env.NODE_ENV
between client and server.The current behavior
Whole UI is unmounted (i.e. no recovery via client-side only rendering) and the following errors are logged:
Errors when landing on the page
The expected behavior
Not sure since I wouldn't be surprised if React couldn't do anything about it considering it probably unmounts its own
script
tag?React 17 behavior: https://codesandbox.io/s/react-17-hydration-mismatch-in-document-m22vv
The good thing is that frameworks can guard against author error by wrapping user code in Suspense boundaries so that any hydration mismatch from user code does not result in throwing away the main script (or too much in general). But that might require a lot of otherwise unnecessary Suspense boundaries (is that a problem?)
The text was updated successfully, but these errors were encountered: