Rerender useSwipeTransition when direction changes #32379
Conversation
github-actions
bot
added
the
React Core Team
This prevents us from clearing the GestureLane while there are still active gestures.
This clarifies that this is the refined internal type. Currently they're the same thing but won't be forever.
sebmarkbage
force-pushed
the
swipedirection
branch
from
542f840 to
0a3c321
Compare
This comment was marked as spam.
This comment was marked as spam.
| // has happened. However, if one direction has the same value as current we | ||
| // know that it's probably not that direction since it won't do anything anyway. | ||
| // TODO: Add an explicit option to provide this. | ||
| queue.initialDirection = previous === current; |
There was a problem hiding this comment.
Double checking my understanding: Seems that if this is wrong, the result is an immediate cancel, rerender with the correct direction, but that rerender would have no effect if its a single direction gesture.
For the stack navigation use case, if there's no page to go back to, previous and current would be the same, making the initial direction next. If you are in the middle of a stack and can go in both directions, then this is just a guess and we rely on the immediate cancel when moving to next.
There was a problem hiding this comment.
Yea. It's only relevant when you start the gesture on like touchdown and haven't moved yet. If it starts once you've moved like in the example in the stacked PRs, which starts on scroll, then you'd pass in the conceptual center offset and you'd already have moved in some direction before you start.
Starting early is mainly interesting to attach a ScrollTimeline before something moves so that if it does move the first frame doesn't lag. For example if you are mostly relying on native scrolling moving the content around but there's like one thing that can snap to either the top or inline in the content that you want to transition. By starting the transition on touchdown you can avoid lagging a frame.
However, this is a little fragile anyway because if something needs to suspend you might lag anyway and if you switch direction you have to be one frame behind anyway. So it's really only in these cases where this guess is useful and even then you could just pass it in explicitly if you wanted to since you'd know the only direction it can go. It's just a convenience for when it does work and playing with out of the box.
| @@ -68,10 +68,12 @@ export default function Page({url, navigate}) { | |||
| activeGesture.current = null; | |||
| cancelGesture(); | |||
| } | |||
| // Reset scroll | |||
| swipeRecognizer.current.scrollLeft = !show ? 0 : 10000; | |||
There was a problem hiding this comment.
This is just an example cleanup to make the fixture reset between scrolls, right? Or am I missing something where setting scrollLeft would be relevant to direction rerenders?
There was a problem hiding this comment.
Yea, this is just to make sure it resets. In the follow up #32422 I'm expanding this a bit to add proper snapping and updating the canonical state if you go over 50%. However, I'm realizing now that I can just delete this now from #32422 because it'll either just have already snapped back by the time scrollend happens or it'll reset by the effect that happens after the new update commits.
We can only render one direction at a time with View Transitions. When the direction changes we need to do another render in the new direction (returning previous or next). To determine direction we store the position we started at and anything moving to a lower value (left/up) is "previous" direction (`false`) and anything else is "next" (`true`) direction. For the very first render we won't know which direction you're going since you're still on the initial position. It's useful to start the render to allow the view transition to take control before anything shifts around so we start from the original position. This is not guaranteed though if the render suspends. For now we start the first render by guessing the direction such as if we know that prev/next are the same as current. With the upcoming auto start mode we can guess more accurately there before we start. We can also add explicit APIs to `startGesture` but ideally it wouldn't matter. Ideally we could just start after the first change in direction from the starting point. DiffTrain build for [88479c6](88479c6)
Stacked on #32379 Track the range offsets along the timeline where previous/current/next is. This can also be specified as an option. This lets you model more than three states along a timeline by clamping them and then updating the "current" as you go. It also allows specifying the "current" offset as something different than what it was when the gesture started such as if it has to start after scroll has already happened (such as what happens if you listen to the "scroll" event).
Stacked on #32379 Track the range offsets along the timeline where previous/current/next is. This can also be specified as an option. This lets you model more than three states along a timeline by clamping them and then updating the "current" as you go. It also allows specifying the "current" offset as something different than what it was when the gesture started such as if it has to start after scroll has already happened (such as what happens if you listen to the "scroll" event). DiffTrain build for [662957c](662957c)
We can only render one direction at a time with View Transitions. When the direction changes we need to do another render in the new direction (returning previous or next).
To determine direction we store the position we started at and anything moving to a lower value (left/up) is "previous" direction (
false) and anything else is "next" (true) direction.For the very first render we won't know which direction you're going since you're still on the initial position. It's useful to start the render to allow the view transition to take control before anything shifts around so we start from the original position. This is not guaranteed though if the render suspends.
For now we start the first render by guessing the direction such as if we know that prev/next are the same as current. With the upcoming auto start mode we can guess more accurately there before we start. We can also add explicit APIs to
startGesturebut ideally it wouldn't matter. Ideally we could just start after the first change in direction from the starting point.