useTransition improvements #17418
Closed
useTransition improvements #17418
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
|
@CompuIves Any idea why CodeSandbox CI isn't running on this PR? |
Details of bundled changes.Comparing: f2fd484...734285d react-dom
react-test-renderer
react-native-renderer
react-art
react-reconciler
Size changes (experimental) |
Details of bundled changes.Comparing: f2fd484...734285d react-art
react-reconciler
react-native-renderer
react-dom
react-test-renderer
ReactDOM: size: 🔺+1.8%, gzip: 🔺+2.2% Size changes (stable) |
acdlite
force-pushed
the
transition-improvements
branch
5 times, most recently
from
2c169a5
to
98cebf8
Compare
|
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 734285d:
|
acdlite
force-pushed
the
transition-improvements
branch
2 times, most recently
from
cf22a72
to
e7fd438
Compare
acdlite
force-pushed
the
transition-improvements
branch
from
e7fd438
to
6de58f6
Compare
acdlite
force-pushed
the
transition-improvements
branch
3 times, most recently
from
19a5e82
to
5c0fd23
Compare
acdlite
force-pushed
the
transition-improvements
branch
3 times, most recently
from
aa759fb
to
da8c9f2
Compare
1 task
acdlite
force-pushed
the
transition-improvements
branch
2 times, most recently
from
2400d7b
to
2510ef2
Compare
acdlite
force-pushed
the
transition-improvements
branch
3 times, most recently
from
6a30245
to
0294458
Compare
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.
acdlite
force-pushed
the
transition-improvements
branch
4 times, most recently
from
6f18dfd
to
b11cff3
Compare
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.
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.
acdlite
force-pushed
the
transition-improvements
branch
from
b11cff3
to
734285d
Compare
|
Closed in favor of #17908 |
acdlite
added a commit
to acdlite/react
that referenced
this pull request
Jan 27, 2021
When multiple transitions update the same queue, only the most recent one should be allowed to finish. We shouldn't show intermediate states. See facebook#17418 for background on why this is important. The way this currently works is that we always assign the same lane to all transitions. It's impossible for one transition to finish without also finishing all the others. The downside of the current approach is that it's too aggressive. Not all transitions are related to each other, so one should not block the other. The new approach is to only entangle transitions if they update one or more of the same state hooks (or class components), because this indicates that they are related. If they are unrelated, then they can finish in any order, as long as they have different lanes. However, this commit does not change anything about how the lanes are assigned. All it does is add the mechanism to entangle per queue. So it doesn't actually change any behavior, yet. But it's a requirement for my next step, which is to assign different lanes to consecutive transitions until we run out and cycle back to the beginning. To avoid too many combinations of behavior, I'm reusing the feature flag I added in my last PR (enableTransitionEntanglement). I'll wait until the existing behavior has rolled out before landing this one.
acdlite
added a commit
to acdlite/react
that referenced
this pull request
Jan 27, 2021
When multiple transitions update the same queue, only the most recent one should be allowed to finish. We shouldn't show intermediate states. See facebook#17418 for background on why this is important. The way this currently works is that we always assign the same lane to all transitions. It's impossible for one transition to finish without also finishing all the others. The downside of the current approach is that it's too aggressive. Not all transitions are related to each other, so one should not block the other. The new approach is to only entangle transitions if they update one or more of the same state hooks (or class components), because this indicates that they are related. If they are unrelated, then they can finish in any order, as long as they have different lanes. However, this commit does not change anything about how the lanes are assigned. All it does is add the mechanism to entangle per queue. So it doesn't actually change any behavior, yet. But it's a requirement for my next step, which is to assign different lanes to consecutive transitions until we run out and cycle back to the beginning.
acdlite
added a commit
to acdlite/react
that referenced
this pull request
Jan 27, 2021
When multiple transitions update the same queue, only the most recent one should be allowed to finish. We shouldn't show intermediate states. See facebook#17418 for background on why this is important. The way this currently works is that we always assign the same lane to all transitions. It's impossible for one transition to finish without also finishing all the others. The downside of the current approach is that it's too aggressive. Not all transitions are related to each other, so one should not block the other. The new approach is to only entangle transitions if they update one or more of the same state hooks (or class components), because this indicates that they are related. If they are unrelated, then they can finish in any order, as long as they have different lanes. However, this commit does not change anything about how the lanes are assigned. All it does is add the mechanism to entangle per queue. So it doesn't actually change any behavior, yet. But it's a requirement for my next step, which is to assign different lanes to consecutive transitions until we run out and cycle back to the beginning.
acdlite
added a commit
to acdlite/react
that referenced
this pull request
Jan 27, 2021
When multiple transitions update the same queue, only the most recent one should be allowed to finish. We shouldn't show intermediate states. See facebook#17418 for background on why this is important. The way this currently works is that we always assign the same lane to all transitions. It's impossible for one transition to finish without also finishing all the others. The downside of the current approach is that it's too aggressive. Not all transitions are related to each other, so one should not block the other. The new approach is to only entangle transitions if they update one or more of the same state hooks (or class components), because this indicates that they are related. If they are unrelated, then they can finish in any order, as long as they have different lanes. However, this commit does not change anything about how the lanes are assigned. All it does is add the mechanism to entangle per queue. So it doesn't actually change any behavior, yet. But it's a requirement for my next step, which is to assign different lanes to consecutive transitions until we run out and cycle back to the beginning.
acdlite
added a commit
that referenced
this pull request
Jan 27, 2021
When multiple transitions update the same queue, only the most recent one should be allowed to finish. We shouldn't show intermediate states. See #17418 for background on why this is important. The way this currently works is that we always assign the same lane to all transitions. It's impossible for one transition to finish without also finishing all the others. The downside of the current approach is that it's too aggressive. Not all transitions are related to each other, so one should not block the other. The new approach is to only entangle transitions if they update one or more of the same state hooks (or class components), because this indicates that they are related. If they are unrelated, then they can finish in any order, as long as they have different lanes. However, this commit does not change anything about how the lanes are assigned. All it does is add the mechanism to entangle per queue. So it doesn't actually change any behavior, yet. But it's a requirement for my next step, which is to assign different lanes to consecutive transitions until we run out and cycle back to the beginning.
koto
pushed a commit
to koto/react
that referenced
this pull request
Jun 15, 2021
When multiple transitions update the same queue, only the most recent one should be allowed to finish. We shouldn't show intermediate states. See facebook#17418 for background on why this is important. The way this currently works is that we always assign the same lane to all transitions. It's impossible for one transition to finish without also finishing all the others. The downside of the current approach is that it's too aggressive. Not all transitions are related to each other, so one should not block the other. The new approach is to only entangle transitions if they update one or more of the same state hooks (or class components), because this indicates that they are related. If they are unrelated, then they can finish in any order, as long as they have different lanes. However, this commit does not change anything about how the lanes are assigned. All it does is add the mechanism to entangle per queue. So it doesn't actually change any behavior, yet. But it's a requirement for my next step, which is to assign different lanes to consecutive transitions until we run out and cycle back to the beginning.
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.
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).
Here's the CodeSandbox I'm using to test the changes: https://codesandbox.io/s/elastic-hawking-69381. It's a tab switcher. Switch tabs and pay attention to the pending spinners.