Support document rendering #24523
Merged
Support document rendering #24523
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
Previously Document was not handled effectively as a container. in particual when hydrating if there was a fallback to client rendering React would attempt to append a new <html> element into the document before clearing out the existing one which errored leaving the application in brokent state. The initial approach I took was to recycle the documentElement and never remove or append it, always just moving it to the right fiber and appending the right children (heady/body) as needed. However in testing a simple approach in modern browsers it seems like treating the documentElement like any other element works fine. This change modifies the clearContainer method to remove the documentElement if the container is a DOCUMENT_NODE. Once the container is cleared React can append a new documentElement via normal means.
previously rendering into Document was broken and only hydration worked because React did not properly deal with the documentElement and would error in a broken state if used that way. With the previous commit addressing this limitation this change re-adds Document as a valid container for createRoot. It should be noted that if you use document with createRoot it will drop anything a 3rd party scripts adds the page before rendering for the first time.
|
Comparing: d20c3af...0215c83 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: (No significant changes) |
sebmarkbage
approved these changes
May 9, 2022
This was referenced May 10, 2022
|
Any eta on when this will be shipped? |
|
Hopefully within the next two weeks. |
|
Looking to check on an updated timeline estimate for this and 18.2? This PR resolves issues that I experience with SSR, but other libraries which mark React as a peer dependency are upset when I am having to |
|
You can use Yarn |
This was referenced Mar 4, 2023
This was referenced Nov 11, 2024
This was referenced Nov 11, 2024
This was referenced Nov 11, 2024
This was referenced Nov 11, 2024
This was referenced Nov 11, 2024
This was referenced Nov 12, 2024
This was referenced Nov 12, 2024
This was referenced Nov 12, 2024
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.
Hydrating into Document
This PR addressed the most fundamental issue identified in #22833. In that issue a hydration mismatch when hydrating into the Document caused a broken application because the client rendered fallback could not append any content to the Document.
This is caused by the fact that a Document can only have 1 element at a time, namely the documentElement which is usually
<html>and by not removing it beforehand the append of a new<html>element fails.Initially I looked into recycling the documentElement so it is never removed or appended but just moved around to whatever fiber needs it, staying in the Document tree as its root. This worked fine but added some code on hot paths and a bit of size.
I then looked at what would happen if we simply removed the documentElement (i.e. treat it like any other Element) and in Chrome, Safari, and Firefox (modern versions) there seems to be no issue with this. This PR is much smaller and simply updates
clearContainerto properly clear the Document as a container so that a later appendChild of an<html>element will not violation Document invariantsHydration into Document compatibility with 3rd party scripts and Extensions
The original issue shows an extension breaking a React application. This PR does not introduce compatibility with extensions or 3rd party scripts that modify the DOM before React hydrates, it simply inverts what gets broken. This change would result in (worst case) React breaking the extension rather than the extension breaking React.
createRoot for Document
as a consequence of the fix for hydration in Document using Document as a root should work now. This PR also adds back types for using createRoot on Document. It should be noted that doing so will effectively wipe out the entire document so third party styles and other DOM elements created by server response, 3rd party scripts, or extensions will be dropped. This is probably not that useful a feature but since it is supported by implementation with no special casing I added back in