Validate DOM nesting for hydration before the hydration warns / errors #28434
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If there's invalid dom nesting, there will be mismatches following but the nesting is the most important cause. We could also silence the mismatch warning (but not thrown error) too.
This really relies on us throwing to abort hydrating siblings so we don't get extra mismatches after.
That this is according to the rules of HTML, not React, and that this will cause a hydration error if not addressed. "appear as" is a bit academic.
Because otherwise we'll act as if we're already inside the child so the child is already inside itself. I don't think we use the context for anything at runtime.
facebook-github-bot
added
CLA Signed
React Core Team
sebmarkbage
force-pushed
the
hydrationnesting
branch
from
49533a7
to
36c6e7e
Compare
rickhanlonii
approved these changes
Feb 24, 2024
|
Comparing: d579e77...353871a Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: Expand to show
|
gnoff
approved these changes
Feb 24, 2024
There was a problem hiding this comment.
I know it’s pedantic but these invalid nestings can only cause hydration issues if you SSR+hydrate. React can actually render these invalid nestings just fine for new trees because there is no parsing involved.
the original message is “react doesn’t support invalid HTML nesting” and the new message is focused more on hydration itself which might make it seem more like this is a hydration problem than just incorrect HTML.
Maybe we the hydration specific warning message during hudration and a non hydration specific message when not hydrating?
|
The issue is that you can get the message while client navigating or loading something, in development, which may then cause a hydration error in production or in another scenario when you MPA nav. That's the reason the warning exists in other cases in the first place. So it's easier to just keep it short. |
sebmarkbage
force-pushed
the
hydrationnesting
branch
3 times, most recently
from
0f62354
to
3747687
Compare
|
Ah yeah that makes sense |
|
Nice improvement. |
sebmarkbage
force-pushed
the
hydrationnesting
branch
from
3747687
to
353871a
Compare
huozhi
added a commit
to vercel/next.js
that referenced
this pull request
Feb 26, 2024
### React upstream changes - facebook/react#28438 - facebook/react#28436 - facebook/react#25954 - facebook/react#28434 - facebook/react#28433 - facebook/react#28432 - facebook/react#28415 - facebook/react#27903 - facebook/react#28430 - facebook/react#28424 - facebook/react#28400 - facebook/react#28422 - facebook/react#28423 - facebook/react#28412 - facebook/react#28418 - facebook/react#28421 - facebook/react#28417 - facebook/react#28399 - facebook/react#28408 - facebook/react#28350 - facebook/react#28387 - facebook/react#28403 - facebook/react#28384 - facebook/react#28409 - facebook/react#28398 - facebook/react#28405 - facebook/react#28328 - facebook/react#28402 - facebook/react#28386 - facebook/react#28388 - facebook/react#28379 - facebook/react#28383 - facebook/react#28390 - facebook/react#28389 - facebook/react#28382 - facebook/react#28348 Closes NEXT-2600
EdisonVan
pushed a commit
to EdisonVan/react
that referenced
this pull request
Apr 15, 2024
facebook#28434) If there's invalid dom nesting, there will be mismatches following but the nesting is the most important cause of the problem. Previously we would include the DOM nesting when rerendering thanks to the new model of throw and recovery. However, the log would come during the recovery phase which is after we've already logged that there was a hydration mismatch. People would consistently miss this log. Which is fair because you should always look at the first log first as the most probable cause. This ensures that we log in the hydration phase if there's a dom nesting issue. This assumes that the consequence of nesting will appear such that the won't have a mismatch before this. That's typically the case because the node will move up and to be a later sibling. So as long as that happens and we keep hydrating depth first, it should hold true. There might be an issue if there's a suspense boundary between the nodes we'll find discover the new child in the outer path since suspense boundaries as breadth first. Before: <img width="996" alt="Screenshot 2024-02-23 at 7 34 01 PM" src="https://github.com/facebook/react/assets/63648/af70cf7f-898b-477f-be39-13b01cfe585f"> After: <img width="853" alt="Screenshot 2024-02-23 at 7 22 24 PM" src="https://github.com/facebook/react/assets/63648/896c6348-1620-4f99-881d-b6069263925e"> Cameo: RSC stacks.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If there's invalid dom nesting, there will be mismatches following but the nesting is the most important cause of the problem.
Previously we would include the DOM nesting when rerendering thanks to the new model of throw and recovery. However, the log would come during the recovery phase which is after we've already logged that there was a hydration mismatch.
People would consistently miss this log. Which is fair because you should always look at the first log first as the most probable cause.
This ensures that we log in the hydration phase if there's a dom nesting issue. This assumes that the consequence of nesting will appear such that the won't have a mismatch before this. That's typically the case because the node will move up and to be a later sibling. So as long as that happens and we keep hydrating depth first, it should hold true. There might be an issue if there's a suspense boundary between the nodes we'll find discover the new child in the outer path since suspense boundaries as breadth first.
Before:
After:
Cameo: RSC stacks.