Selective Hydration #16880
Merged
Selective Hydration #16880
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: a06d181...46df9f1 react-dom
react-reconciler
|
sebmarkbage
force-pushed
the
selectivehydration
branch
from
d934ed3
to
6dd28ce
Compare
sebmarkbage
force-pushed
the
selectivehydration
branch
from
6dd28ce
to
46df9f1
Compare
acdlite
approved these changes
Sep 25, 2019
| } | ||
| break; | ||
| case SuspenseComponent: | ||
| flushSync(() => scheduleWork(fiber, Sync)); |
There was a problem hiding this comment.
I find the methods that automatically flush at the end confusing unless they are at the bottom of the stack. In the work loop I've started to prefer using two separate calls, one to queue the sync work and a second explicit call that flushes it.
There was a problem hiding this comment.
Yea I also don't like the closure. I would've done it that way but didn't feel justified to move this whole function into WorkLoop. Although the split between WorkLoop and Reconciler is a bit arbitrary right now. Reconciler is effectively just a smaller set of exposed functions from WorkLoop.
| let root: FiberRoot = fiber.stateNode; | ||
| if (root.hydrate) { | ||
| // Flush the first scheduled "update". | ||
| flushRoot(root, root.firstPendingTime); |
There was a problem hiding this comment.
Yeah this is kind of weird but it makes sense :D
I suppose the other way to model this is, when hydrating, immediately commit the root in a dehydrated state.
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.
Because hydration in concurrent mode is yieldy, we can switch hydration priority when new events come in. Selective Hydration gives us the ability to increase priority of roots and suspense boundaries based on what is being interacted with.
Discrete events are replayed in order. They are based an intentional user action so they normally have pretty high priority.
Replaying has some quirks given that we don't know if preventDefault will be called or not. Normally we allow the default behavior. However, a lot of times we'll already have received the data necessary to unblock a boundary. I.e. we're CPU bound.
This PR attempts to first synchronously hydrate the path to the discrete target. Only if that fails, do we create a queue to be replayed later.
Currently, hydration of boundaries bump to Normal pri once Suspense thennables resolve which is a bug. However, we probably also want these thennables to schedule work at even higher priority if they're blocking discrete events. I'll do that in a follow up.