Refactor Expiration Time Model #17669
Closed
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
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 0699c38:
|
Details of bundled changes.Comparing: e706721...0699c38 react-dom
react-test-renderer
react-native-renderer
react-art
react-reconciler
ReactDOM: size: 0.0%, gzip: 0.0% Size changes (experimental) |
Details of bundled changes.Comparing: e706721...0699c38 react-art
react-reconciler
react-native-renderer
react-dom
react-test-renderer
ReactDOM: size: 🔺+1.6%, gzip: 🔺+1.8% Size changes (stable) |
Follow up to facebook#17484, which was reverted due to a bug found in www.
When resetting render phase updates after a throw, we should only clear the pending queue of hooks that were already processed.
Detects if a queue has been processed by whether the hook was cloned. If we change the implementation to an array instead of a list, we'll need some other mechanism to determine whether the hook was processed.
useTransition uses the state hook as part of its implementation, so we need to fork it in the dispatcher used for re-renders, too.
The `isPending` state managed by the `useTransition` queue can be modeled using the same queue as useState/useReducer; that's how it's implemented today. However, since there's only ever a single pending transition per `useTransition` hook, and the most recent one always wins, we don't really need to maintain an entire queue structure. This replaces the internal `useState` queue with a specialized implementation. It tracks the most recent transition expiration time on shared instance object, and the last processed expiration time on each hook copy. When the processed expiration time catches up to the pending one, we know that the transition is no longer pending. At a high level, this is also how the `useState` queue works, but without the overhead of an actual queue. The implementation is also inspired by Suspense boundaries, which also have an internal state for whether the boundary is displaying a fallback, but does not use an actual queue to manage that state.
When multiple transitions update the same queue, only the most recent one should be considered pending. Example: If I switch tabs multiple times, only the last tab I click should display a pending state (e.g. an inline spinner).
When multiple transitions update the same queue, only the most recent one should be allowed to finish. Do not display intermediate states. For example, if you click on multiple tabs in quick succession, we should not switch to any tab that isn't the last one you clicked.
We currently use the expiration time to represent the timeout of a transition. Since we intend to stop treating work priority as a timeline, we can no longer use this trick. In this commit, I've changed it to store the event time on the update object instead. Long term, we will store event time on the root as a map of transition -> event time. I'm only storing it on the update object as a temporary workaround to unblock the rest of the changes.
acdlite
force-pushed
the
expiration-time-refactor
branch
from
e062ad7
to
4903dd2
Compare
I'm about to remove the expiration times train model. This commit fixes tests that are coupled to that model's implementation. I have intentionally made these changes in their own commit, without changing any of the implementation, to show that they pass both before and after. I disabled some tests that are inherently coupled to expiration times. Some of them may need to be replaced with an equivalent test once the new model is in place.
|
Can close this? |
|
Closing as stale. |
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.
Based on #17418
Stack of changes to replace our "expiration time" model with something better.