-
Notifications
You must be signed in to change notification settings - Fork 47.2k
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
[Selective Hydration] Increase priority for non-synchronous discrete events and retries #16935
Conversation
ReactDOM: size: 0.0%, gzip: 0.0% Details of bundled changes.Comparing: 3694a3b...3381578 react-dom
react-reconciler
|
await promise; | ||
|
||
// After the click, we should prioritize D and the Click first, | ||
// and only after that render A and C. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you copy-pasted this comment but forgot to update it
96ee8ba
to
3381578
Compare
I wonder, would this have future affects on Flare? It doesn't matter right now, but if you think it does a test that is skipped for Flare would be useful. |
The way I'm thinking about it is that we're testing the interaction between event system <-> replaying system in PartialHydration file which has tests for both. In this, SelectiveHydration, file we're testing the interaction between event replaying <-> reconciler priorities. We're actually testing the reconciler here, more than the events themselves. So we don't need to duplicate every combination of these tests. |
If an increased priority dehydrated boundary commits as dehydrated because it is suspended, it no longer has any
expirationTime
scheduled. So when the thenable resolves, it gets the default priority. This increases theretryTime
. This will almost immediately expire and effectively become sync. We might want to make this slightly higher than Normal but longer expiration time.The upside of eagerly computing this (as opposed to when resolved) is that we can guarantee a predictable order of priorities. (First event in, highest pri.)
This PR also ensures that we increase the priority of subsequent events after the first can't be done synchronously. There's no reason to keep them as high as sync since at that point it is already too late since replaying has kicked in. So we schedule with user blocking pri for this case.