[Fiber] Suspend the commit while we wait for the previous View Transition to finish #32002
+55
−5
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
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
facebook-github-bot
added
CLA Signed
React Core Team
|
Comparing: 38127b2...f7f4337 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: (No significant changes) |
acdlite
approved these changes
Jan 7, 2025
sebmarkbage
force-pushed
the
viewtransitiondelay
branch
from
5b9fb22 to
2b1b471
Compare
github-actions bot
pushed a commit
that referenced
this pull request
Jan 8, 2025
…tion to finish (#32002) Stacked on #31975. View Transitions cannot handle interruptions in that if you start a new one before the previous one has finished, it just stops and then restarts. It doesn't seamlessly transition into the new transition. This is generally considered a bad thing but I actually think it's quite good for fire-and-forget animations (gestures is another story). There are too many examples of bad animations in fast interactions because the scenario wasn't predicted. Like overlapping toasts or stacked layers that look bad. The only case interrupts tend to work well is when you do a strict reversal of an animation like returning to the page you just left or exiting a modal just being opened. However, we're limited by the platform even in that regard. I think one reason interruptions have traditionally been seen as good is because it's hard if you have a synchronous framework to not interrupt since your application state has already moved on. We don't have that limitation since we can suspend commits. We can do all the work to prepare for the next commit by rendering while the animation is going but then delay the commit until the previous one finishes. Another technical limitation earlier animation libraries suffered from is only have the option to either interrupt or sequence animations since it's modeling just one change set. Like showing one toast at a time. That's bad. We don't have that limitation because we can interrupt a previously suspended commit and start working on a new one instead. That's what we do for suspended transitions in general. The net effect is that we batch the commits. Therefore if you get multiple toasts flying in fast, they can animate as a batch in together all at once instead of overlapping slightly or being staggered. Interruptions (often) bad. Staggered animations bad. Batched animations good. This PR stashes the currently active View Transition with an expando on the container that's animating (currently always document). This is similar to what we do with event handlers etc. We reason we do this with an expando is that if you have multiple Reacts on the same page they need to wait for each other. However, one of those might also be the SSR runtime. So this lets us wait for the SSR runtime's animations to finish before starting client ones. This could really be a more generic name since this should ideally be shared across frameworks. It's kind of strange that this property doesn't already exist in the DOM given that there can only be one. It would be useful to be able to coordinate this across libraries. DiffTrain build for [98418e8](98418e8)
github-actions bot
pushed a commit
that referenced
this pull request
Jan 8, 2025
…tion to finish (#32002) Stacked on #31975. View Transitions cannot handle interruptions in that if you start a new one before the previous one has finished, it just stops and then restarts. It doesn't seamlessly transition into the new transition. This is generally considered a bad thing but I actually think it's quite good for fire-and-forget animations (gestures is another story). There are too many examples of bad animations in fast interactions because the scenario wasn't predicted. Like overlapping toasts or stacked layers that look bad. The only case interrupts tend to work well is when you do a strict reversal of an animation like returning to the page you just left or exiting a modal just being opened. However, we're limited by the platform even in that regard. I think one reason interruptions have traditionally been seen as good is because it's hard if you have a synchronous framework to not interrupt since your application state has already moved on. We don't have that limitation since we can suspend commits. We can do all the work to prepare for the next commit by rendering while the animation is going but then delay the commit until the previous one finishes. Another technical limitation earlier animation libraries suffered from is only have the option to either interrupt or sequence animations since it's modeling just one change set. Like showing one toast at a time. That's bad. We don't have that limitation because we can interrupt a previously suspended commit and start working on a new one instead. That's what we do for suspended transitions in general. The net effect is that we batch the commits. Therefore if you get multiple toasts flying in fast, they can animate as a batch in together all at once instead of overlapping slightly or being staggered. Interruptions (often) bad. Staggered animations bad. Batched animations good. This PR stashes the currently active View Transition with an expando on the container that's animating (currently always document). This is similar to what we do with event handlers etc. We reason we do this with an expando is that if you have multiple Reacts on the same page they need to wait for each other. However, one of those might also be the SSR runtime. So this lets us wait for the SSR runtime's animations to finish before starting client ones. This could really be a more generic name since this should ideally be shared across frameworks. It's kind of strange that this property doesn't already exist in the DOM given that there can only be one. It would be useful to be able to coordinate this across libraries. DiffTrain build for [98418e8](98418e8)
github-actions bot
pushed a commit
to code/lib-react
that referenced
this pull request
Jan 8, 2025
…tion to finish (facebook#32002) Stacked on facebook#31975. View Transitions cannot handle interruptions in that if you start a new one before the previous one has finished, it just stops and then restarts. It doesn't seamlessly transition into the new transition. This is generally considered a bad thing but I actually think it's quite good for fire-and-forget animations (gestures is another story). There are too many examples of bad animations in fast interactions because the scenario wasn't predicted. Like overlapping toasts or stacked layers that look bad. The only case interrupts tend to work well is when you do a strict reversal of an animation like returning to the page you just left or exiting a modal just being opened. However, we're limited by the platform even in that regard. I think one reason interruptions have traditionally been seen as good is because it's hard if you have a synchronous framework to not interrupt since your application state has already moved on. We don't have that limitation since we can suspend commits. We can do all the work to prepare for the next commit by rendering while the animation is going but then delay the commit until the previous one finishes. Another technical limitation earlier animation libraries suffered from is only have the option to either interrupt or sequence animations since it's modeling just one change set. Like showing one toast at a time. That's bad. We don't have that limitation because we can interrupt a previously suspended commit and start working on a new one instead. That's what we do for suspended transitions in general. The net effect is that we batch the commits. Therefore if you get multiple toasts flying in fast, they can animate as a batch in together all at once instead of overlapping slightly or being staggered. Interruptions (often) bad. Staggered animations bad. Batched animations good. This PR stashes the currently active View Transition with an expando on the container that's animating (currently always document). This is similar to what we do with event handlers etc. We reason we do this with an expando is that if you have multiple Reacts on the same page they need to wait for each other. However, one of those might also be the SSR runtime. So this lets us wait for the SSR runtime's animations to finish before starting client ones. This could really be a more generic name since this should ideally be shared across frameworks. It's kind of strange that this property doesn't already exist in the DOM given that there can only be one. It would be useful to be able to coordinate this across libraries. DiffTrain build for [98418e8](facebook@98418e8)
github-actions bot
pushed a commit
to code/lib-react
that referenced
this pull request
Jan 8, 2025
…tion to finish (facebook#32002) Stacked on facebook#31975. View Transitions cannot handle interruptions in that if you start a new one before the previous one has finished, it just stops and then restarts. It doesn't seamlessly transition into the new transition. This is generally considered a bad thing but I actually think it's quite good for fire-and-forget animations (gestures is another story). There are too many examples of bad animations in fast interactions because the scenario wasn't predicted. Like overlapping toasts or stacked layers that look bad. The only case interrupts tend to work well is when you do a strict reversal of an animation like returning to the page you just left or exiting a modal just being opened. However, we're limited by the platform even in that regard. I think one reason interruptions have traditionally been seen as good is because it's hard if you have a synchronous framework to not interrupt since your application state has already moved on. We don't have that limitation since we can suspend commits. We can do all the work to prepare for the next commit by rendering while the animation is going but then delay the commit until the previous one finishes. Another technical limitation earlier animation libraries suffered from is only have the option to either interrupt or sequence animations since it's modeling just one change set. Like showing one toast at a time. That's bad. We don't have that limitation because we can interrupt a previously suspended commit and start working on a new one instead. That's what we do for suspended transitions in general. The net effect is that we batch the commits. Therefore if you get multiple toasts flying in fast, they can animate as a batch in together all at once instead of overlapping slightly or being staggered. Interruptions (often) bad. Staggered animations bad. Batched animations good. This PR stashes the currently active View Transition with an expando on the container that's animating (currently always document). This is similar to what we do with event handlers etc. We reason we do this with an expando is that if you have multiple Reacts on the same page they need to wait for each other. However, one of those might also be the SSR runtime. So this lets us wait for the SSR runtime's animations to finish before starting client ones. This could really be a more generic name since this should ideally be shared across frameworks. It's kind of strange that this property doesn't already exist in the DOM given that there can only be one. It would be useful to be able to coordinate this across libraries. DiffTrain build for [98418e8](facebook@98418e8)
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.
Stacked on #31975.
View Transitions cannot handle interruptions in that if you start a new one before the previous one has finished, it just stops and then restarts. It doesn't seamlessly transition into the new transition.
This is generally considered a bad thing but I actually think it's quite good for fire-and-forget animations (gestures is another story). There are too many examples of bad animations in fast interactions because the scenario wasn't predicted. Like overlapping toasts or stacked layers that look bad. The only case interrupts tend to work well is when you do a strict reversal of an animation like returning to the page you just left or exiting a modal just being opened. However, we're limited by the platform even in that regard.
I think one reason interruptions have traditionally been seen as good is because it's hard if you have a synchronous framework to not interrupt since your application state has already moved on. We don't have that limitation since we can suspend commits. We can do all the work to prepare for the next commit by rendering while the animation is going but then delay the commit until the previous one finishes.
Another technical limitation earlier animation libraries suffered from is only have the option to either interrupt or sequence animations since it's modeling just one change set. Like showing one toast at a time. That's bad. We don't have that limitation because we can interrupt a previously suspended commit and start working on a new one instead. That's what we do for suspended transitions in general. The net effect is that we batch the commits.
Therefore if you get multiple toasts flying in fast, they can animate as a batch in together all at once instead of overlapping slightly or being staggered. Interruptions (often) bad. Staggered animations bad. Batched animations good.
This PR stashes the currently active View Transition with an expando on the container that's animating (currently always document). This is similar to what we do with event handlers etc. We reason we do this with an expando is that if you have multiple Reacts on the same page they need to wait for each other. However, one of those might also be the SSR runtime. So this lets us wait for the SSR runtime's animations to finish before starting client ones. This could really be a more generic name since this should ideally be shared across frameworks. It's kind of strange that this property doesn't already exist in the DOM given that there can only be one. It would be useful to be able to coordinate this across libraries.