Support document rendering #24523
Support document rendering #24523
Conversation
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) |
|
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 |
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