Allow passing range option to useSwipeTransition #32412
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
github-actions
bot
added
the
React Core Team
sebmarkbage
force-pushed
the
swipeoptions
branch
from
14a2d6c to
a225489
Compare
sebmarkbage
force-pushed
the
swipeoptions
branch
from
a225489 to
9551248
Compare
…t is Also, let you specify this as options. This lets you model more than three states along a timeline by clamping them. 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 scroll has already happened.
This avoids a case where we'd switch to previous when returning to 0 where 0 was also the starting point.
sebmarkbage
force-pushed
the
swipeoptions
branch
from
f40fe8d to
a9526df
Compare
jackpope
approved these changes
Feb 21, 2025
Comment on lines
+4024
to
+4034
| currentOffset < rangeCurrent | ||
| ? isFlippedDirection | ||
| : currentOffset > rangeCurrent | ||
| ? !isFlippedDirection | ||
| : // Otherwise, look for an explicit option. | ||
| gestureOptions && gestureOptions.direction === 'next' | ||
| ? true | ||
| : gestureOptions && gestureOptions.direction === 'previous' | ||
| ? false | ||
| : // If no option is specified, imply from the values specified. | ||
| queue.initialDirection; |
There was a problem hiding this comment.
The nested ternaries are tough to reason about here. Might be more readable in if blocks.
Took some stepping through to realize we only look for the gestureOptions.direction or queue.initialDirection if the currentOffset is the rangeCurrent. I had expected an explicit direction object to override when available. But I guess it makes sense to base off movement because even a one-way gesture needs to be able to reset if its pulled back the other way.
There was a problem hiding this comment.
Ah I see from the next PR that the movement may have started before the scroll event. Which the currentOffset can represent here.
github-actions bot
pushed a commit
that referenced
this pull request
Feb 21, 2025
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)
sebmarkbage
added a commit
that referenced
this pull request
Feb 21, 2025
Stacked on #32412. To effectively `useSwipeTransition` you need something to start and stop the gesture as well as triggering an Action. This adds an example Gesture Recognizer to the fixture. Instead of having this built-in to React itself, instead the idea is to leave this to various user space Component libraries. It can be done in different ways for different use cases. It could use JS driven or native ScrollTimeline or both. This example uses a native scroll with scroll snapping to two edges. If you swipe far enough to snap to the other edge, it triggers an Action at the end. This particular example uses a `position: sticky` to wrap the content of the Gesture Recognizer. This means that it's inert by itself. It doesn't scroll its content just like a plain JS recognizer using pointer events would. This is useful because it means that scrolling doesn't affect content before we start (the "scroll" event fires after scrolling has already started) so we don't have to both trying to start it earlier. It also means that scrolling doesn't affect the live content which can lead to unexpected effects on the View Transition. I find the inert recognizer the most useful pairing with `useSwipeTransition` but it's not the only way to do it. E.g. you can also have a scrollable surface that uses plain scrolling with snapping and then just progressively enhances swiping between steps.
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 #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).