[Selective Hydration] ReactDOM.unstable_scheduleHydration(domNode) #17004
Conversation
This file contains 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
|
ReactDOM: size: 0.0%, gzip: -0.0% Details of bundled changes.Comparing: 26ba38a...a1cb22c react-dom
react-reconciler
|
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 |
There was a problem hiding this comment.
nit Copy-pasta comment is confusing. There's no D and we don't click anything.
| @@ -841,6 +845,12 @@ const ReactDOM: Object = { | |||
| unstable_createSyncRoot: createSyncRoot, | |||
| unstable_flushControlled: flushControlled, | |||
|
|
|||
| unstable_scheduleHydration(target: Node) { | |||
| if (target) { | |||
There was a problem hiding this comment.
What's the reason behind silently nooping if we're passed an invalid target?
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.
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.
2202d34
to
a1cb22c
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.