-
Notifications
You must be signed in to change notification settings - Fork 47.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Settle on Heuristic/API for Choosing Hydration #10189
Comments
What's downside of a heuristic like |
Personally 3 makes most sense, I'm not sure what argument there is for the current behavior other than reduced API footprint. AFAIK there's no case where the current heuristic is actually beneficial, the callsite should be aware of what it expects should happen. I prefer simpler behavior and explicit APIs. However, it may still be a good idea to mark the root in DEV so that a warning can be emitted. While it has not been an issue yet and may not be an issue in the future, using the DOM as a source of truth is not nice. |
@gaearon seems the result is not correct? |
Not sure what you mean. |
ReactDOM.render(..., container)
can be used on either purely client-side content or on server-side rendered content. If it is client-side, we empty the container first and then render into it. If it is server-side, we hydrate it. We currently use data-reactid to determine if we should hydrate or clear.We could in theory hydrate to patch it up but it's not safe with the current hydration model.
If this is your initial DOM
<div id="container"><div class="spinner">Loading...</div></div>
and then callReactDOM.render(<div class="myapp"><span>App</span></div>, document.getElementById('container'))
intending to do a client-side only render (not hydration).Then you end with
<div id="container"><div class="spinner"><span>App</span></div></div>
. Because we don't patch up the attributes.I see four possible solutions:
Always patch up attributes if they differ. This would be really slow to hydrate in the normal hydration mode and slow down initial render into a non-SSR tree.
Continue to use a heuristic by hydrating when some kind of extra meta data in the HTML is present. Add it in the server-renderer. We can change it so that only one meta data is needed. Not one per element. It can be a comment or an attribute.
Introduce an explicit API to hydrate.
ReactDOM.hydrate(..., container)
. SSR hydration callsites have to be updated.Introduce Option 3 but keep Option 2 with a warning for one major version to make it a non-breaking change. Allows people to incrementally upgrade to
ReactDOM.hydrate
at their leisure.The text was updated successfully, but these errors were encountered: