Skip to content
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

Closed
sebmarkbage opened this issue Jul 15, 2017 · 5 comments
Closed

Settle on Heuristic/API for Choosing Hydration #10189

sebmarkbage opened this issue Jul 15, 2017 · 5 comments
Milestone

Comments

@sebmarkbage
Copy link
Collaborator

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 call ReactDOM.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:

  1. 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.

  2. 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.

  3. Introduce an explicit API to hydrate. ReactDOM.hydrate(..., container). SSR hydration callsites have to be updated.

  4. 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.

@sebmarkbage sebmarkbage added this to the 16.0 milestone Jul 15, 2017
@gaearon
Copy link
Collaborator

gaearon commented Jul 15, 2017

What's downside of a heuristic like data-reactroot? I guess doesn't work for text nodes, is there more?

@syranide
Copy link
Contributor

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
Copy link
Collaborator

gaearon commented Aug 1, 2017

#10339

@gaearon gaearon closed this as completed Aug 1, 2017
@luckydrq
Copy link

luckydrq commented Aug 9, 2017

Then you end with

App

@gaearon seems the result is not correct?

@gaearon
Copy link
Collaborator

gaearon commented Aug 9, 2017

Not sure what you mean.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants