[Selective Hydration] ReactDOM.unstable_scheduleHydration(domNode)#17004
Merged
sebmarkbage merged 1 commit intofacebook:masterfrom Oct 3, 2019
Merged
[Selective Hydration] ReactDOM.unstable_scheduleHydration(domNode)#17004sebmarkbage merged 1 commit intofacebook:masterfrom
sebmarkbage merged 1 commit intofacebook:masterfrom
Conversation
|
ReactDOM: size: 0.0%, gzip: -0.0% Details of bundled changes.Comparing: 26ba38a...a1cb22c react-dom
react-reconciler
|
sebmarkbage
force-pushed
the
explicithydration
branch
from
e92aeb6 to
2202d34
Compare
bvaughn
approved these changes
Oct 3, 2019
| let spanB = container.getElementsByTagName('span')[1]; | ||
| let spanC = container.getElementsByTagName('span')[2]; | ||
|
|
||
| // A and D will be suspended. We'll click on D which should take |
Contributor
There was a problem hiding this comment.
nit Copy-pasta comment is confusing. There's no D and we don't click anything.
| unstable_flushControlled: flushControlled, | ||
|
|
||
| unstable_scheduleHydration(target: Node) { | ||
| if (target) { |
Contributor
There was a problem hiding this comment.
What's the reason behind silently nooping if we're passed an invalid target?
Contributor
Author
There was a problem hiding this comment.
Mostly because it's pretty common to pass in getElementById and probably not worth taking down the site since this feature has no important semantic meaning other than perf. It should probably be a warning at some point though.
Contributor
There was a problem hiding this comment.
Yeah, seems like we should at least warn since the overall scheduling behavior is a bit opaque to begin with. (Might be easy to overlook an error like a misspelled id.)
Adds an API to explicitly prioritize hydrating the path to a particular DOM node without relying on events to do it. The API uses the current scheduler priority to schedule it. For the same priority, the last one wins. This allows a similar effect as continuous events. This is useful for example to hydrate based on scroll position. I considered having an API that explicitly overrides the current target(s). However that makes it difficult to coordinate across components in an app. This just hydrates on target at a time but if it is blocked on I/O we could consider increasing priority of later targets too.
sebmarkbage
force-pushed
the
explicithydration
branch
from
2202d34 to
a1cb22c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds an API to explicitly prioritize hydrating the path to a particular DOM node without relying on events to do it.
The API uses the current scheduler priority to schedule it. For the same priority, the last one wins. This allows a similar effect as continuous events. This is useful for example to hydrate based on scroll position, or prioritize components that will upgrade to client-rendered-only content.
I considered having an API that explicitly overrides the current target(s). However that makes it difficult to coordinate across components in an app.
This just hydrates one target at a time but if it is blocked on I/O we could consider increasing priority of later targets too.