react
react copied to clipboard
facebook
Implement Persistent Host Instances
Background
For a variety of reasons html, head, and body nodes are special in the browser and historically there has not been much heed given to these elements in particular within react-dom which has led to some limitations of interoperability with externals systems such as 3rd party scripts and browser extensions. Additionally new features in React will require some special handling of these instances to be possible.
The main issue has to do with instance lifecycles and React's total ownership of the nodes within it's tree. For the head for instance, if there are stylesheet links inserted by 3rd parties, React might unmount those nodes, or reinsert them somewhere else causing a new fetch and temporary style unloading. Additionally useInsertionEffect runs in the mutation phase but if we are going to be replacing the head it will be unmounted during the time these effects are run so you can't always inject styles when you expected to be able to.
The historical advice has been to render into an element in the body that isn't like to be targeted by any external systems however this conflicts with the guidance for using streaming rendering available in React 18 where it is going to be common that React owns the entire document.
General Approach
To solve these issues, this PR introduces a Psuedo sub-type of HostComponent for react-dom only called a Persistent HostComponent. When we detect that a HostComponent is of the persistent variety different insertion and update semantics are enforced.
- All Persistent HostComponents need to be placed individually, they will not be appended to a parent fiber that has a Placement.
- During completeWork Persistent HostComponents accumulate HostComponent children into a temporary host.
- During commitWork Persistent HostComponents defer insertion to an ad-hoc placement function which is responsible for guaranteeing this desired persistent semantics
react-dom Approach
In the case of react-dom there are three persistent instances, document.documentElement, document.head, document.body. If you render a <html /> | <head /> | <body /> in your tree they each will bind to the already existing Element and not recreate a new one.
Key Constraints:
- none of the 3 persistent nodes will be unmounted at any time
- none of the 3 persistent nodes will be ever change referential identity
- Head and Body nodes will never reposition, reorder, or otherwise alter the placement of style-related nodes outside of React
insertion stability (Body and Head only)
In Body and Head, we expect there to be Nodes that were created by systems other than React. Most items can safely be removed once loaded because they are fire-and-forget, such as scripts. However <style> and <link rel="stylesheet"> nodes need to be retained for proper functioning of a site and as such we expect that these two instances will have a number of Nodes outside the purview of React's runtime which change insertion semantics.
The main challenge here is when React thinks you are placing an instance in tail position it will use appendChild however it may be intentional that 3rd party style nodes actually exist after the React tree. To get around this issue both Body and Head manage a special Comment Node which acts as an insertion anchor. When you might otherwise append, if this insertion anchor exists it will insertBefore instead. This anchor persists even through unmounting so if you completely replace your head or body the new contents will be emitted into the same slot as the old one was deleted out of. This means we can not only support trailing extra nodes but preceding nodes as well. (This will be more important when SSR starts to support first class stylesheet management)
Open Questions
- What do we do about props on persistent instances when react unmounts them? We leave the 3rdparty children in place and we could eliminate the props but we don't know how to restore the attributes to what they were before React mounted, nor is that necessarily correct. The current implementation leaves the props in place
- Is there any special consideration for event handlers that needs to take place?
- Have I avoided the hot paths enough?
- Is it worth the code size?
- Will this feature ever make sense for any other renderer?
Comparing: 6ef466c681c987493432608be56f2e01f94268d7...ec38036b13694a8bb6d14c4409ad3890eefd532c
Critical size changes
Includes critical production bundles, as well as any change greater than 2%:
| Name | +/- | Base | Current | +/- gzip | Base gzip | Current gzip |
|---|---|---|---|---|---|---|
| oss-stable/react-dom/cjs/react-dom.production.min.js | +0.16% | 134.28 kB | 134.50 kB | +0.10% | 42.94 kB | 42.98 kB |
| oss-experimental/react-dom/cjs/react-dom.production.min.js | +1.59% | 140.35 kB | 142.57 kB | +1.71% | 44.74 kB | 45.50 kB |
| facebook-www/ReactDOM-prod.classic.js | +0.10% | 474.44 kB | 474.89 kB | +0.11% | 84.87 kB | 84.97 kB |
| facebook-www/ReactDOM-prod.modern.js | +0.09% | 459.68 kB | 460.11 kB | +0.10% | 82.63 kB | 82.71 kB |
| facebook-www/ReactDOMForked-prod.classic.js | +0.10% | 474.44 kB | 474.89 kB | +0.11% | 84.88 kB | 84.97 kB |
Significant size changes
Includes any change greater than 0.2%:
Expand to show
Generated by :no_entry_sign: dangerJS against ec38036b13694a8bb6d14c4409ad3890eefd532c
In terms of naming, I don't think we can use Persistent for this since we have a whole Persistent Mode that means other things and the term comes up a lot of other places. So this would have to be called something else.
