Add support for hydrating portals
See original GitHub issueDo you want to request a feature or report a bug?
Probably bug, but arguably a feature request, I suppose.
What is the current behavior?
I’ve attempted my best effort at a fiddle that shows off the particular issue. Obviously server side rendering is impossible via JSFiddle, but the markup should be equivalent to having rendered Test
into a div with id test-1
during server side render.
https://jsfiddle.net/y8o5n2zg/
As seen in the fiddle, an attempt to ReactDOM.hydrate() a portal results in:
Warning: Expected server HTML to contain a matching text node for "Hello World" in <div>.
Additionally, after failing to hydrate, React renders the component and appends it resulting in a duplicated section of DOM:
<div id="test-1">Hello WorldHello World</div>
What is the expected behavior?
In an ideal world, calling hydrate on a component that has portals would allow those DOM containers to hydrate into the components they were rendered with.
Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
I’ve only tested this in 16.4.1, but I’ve confirmed the behavior in Chrome and Firefox. Given that I’m really looking at an edge case here I doubt it worked previously.
Why I’m doing this edge-case-y nonsense:
We’re currently using multiple React roots on our pages (as some portions of the pages are not rendered by React yet), most of which are server-side rendered. We’d like to be able to hydrate them into a single React root on page, so that we can share contexts between them without difficulty and without repeating those context components in memory (in some cases we can have a good number of roots on the page—20-30, perhaps?).
In searching, I found a few potentially related bugs (#12615, #10713, #11169), but it seemed like these really didn’t line up with my (hopefully valid?) use case.
Thanks!
Issue Analytics
- State:
- Created 5 years ago
- Reactions:39
- Comments:33 (7 by maintainers)
When you hydrate, the initial render should match your server render. But portals are currently not supported on the server. Therefore, hydrating a portal doesn’t make sense with current limitations.
I think you want to do something like:
Does that make sense? Same workaround as you need to use when your client render doesn’t match.
Still relevant