Track Event Time as the Start Time for Suspense #15358
Merged
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.2%, gzip: -0.3% Details of bundled changes.Comparing: 875d05d...b65f6a4 react-dom
react-art
react-native-renderer
react-test-renderer
react-reconciler
Generated by 🚫 dangerJS |
acdlite
reviewed
Apr 9, 2019
acdlite
reviewed
Apr 9, 2019
acdlite
approved these changes
Apr 9, 2019
sebmarkbage
force-pushed
the
jnd
branch
2 times, most recently
from
ca3c9f9
to
90a186c
Compare
When we switch back from fallback to content, we made progress and we track the time from when we showed the fallback in the first place as the last time we made progress.
This ensures that we don't resuspend unnecessarily if we're just retrying the same exact boundary again. We can still unnecessarily suspend for nested boundaries.
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.
The new suspense model is based on the last "event time" that influenced the suspended render.
The "event time" is the time of the "update" (root render, setState, dispatch) - which we infer from its expiration time.
If this is a "retry", then there is no "update" and the event time is the time we committed the fallback. This event time is only accounted for if we actually switch from fallback to content, i.e. make progress. If we retry and don't make further progress, then this event time isn't accounted for.
To make the math simple and fast, I model the committed time as an "normal pri expiration time" at the time it committed.
Since there can be multiple updates and retries in the same batch, we use the most recent time for our heuristic. That ensures that we at least never wait longer than we otherwise would've.
Since we can't tell the difference between committed and suspended updates, this PR will error on the side of including committed updates.
For now, I still use the hard coded 150ms suspense time starting from the event time. In a follow up, I'll add the Just Noticeable Difference heuristic instead.