Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delta can be negative despite reported direction #353

Closed
isaachinman opened this issue Oct 11, 2024 · 2 comments
Closed

Delta can be negative despite reported direction #353

isaachinman opened this issue Oct 11, 2024 · 2 comments

Comments

@isaachinman
Copy link

I am building some "swipe left to delete" behaviour.

To facilitate this, I am consuming the deltaX and dir properties of the onSwiping event handler. In the case of a Left swipe, we would expect the deltaX to be an increasingly negative number.

However, it is possible to reverse the direction of the swipe, and onSwiping will emit another dir = Left event, but where the deltaX is greater (ie, to the right) of the last event.

Is this behaviour expected? This is thoroughly unexpected in my opinion – if a swipe begins in a left direction but then changes, we should consider that left swipe to be ended.

Not sure how to reconcile this behaviour without keeping track of previous values and essentially "ensuring" the direction instead of trusting the dir property provided.

@hartzis
Copy link
Collaborator

hartzis commented Oct 14, 2024

howdy 👋, this is expected behavior and has been consistent for years.

the data for "onSwiping" is essentially the raw event data that will be used to fire the other callbacks, ie "onSwiped[Left/Right/Up/Down]".

in my view a "swipe" doesn't happen till the user commits to a direction and lets their finger up off the device. So this translates to i'll admit weird results in the "onSwiping" callback if the user is moving their finger back and forth.

you can absolutely track and choose to ignore callbacks if the users direction changes. all the info is present in the callbacks but you do have to manually track like you mentioned.

i do think this experience could be improved within the library maybe with a new prop maybe 🤔, ie "cancelSwipeTrackingOnDirectionChange".

@isaachinman
Copy link
Author

Thanks @hartzis. That does indeed make sense in a way.

My use case: I am building "swipe to reveal" actions on list items in the iOS style. This means I want to track deltaX and apply a transform on a DOM node via a ref.

#299 is directly related. It's not clear how to support this behaviour with react-swipeable. The focus of react-swipeable seems to be the most basic kind of "after swipe" interactions, which is odd and quite limiting.

What I found surprising is that a "left" swipe can actually result in a positive deltaX if the user changes directions and swipes all the way back right.

I was able to get something working quite nicely, but it involves managing several refs on top of react-swipeable.

After spending the past couple years mostly working in the React Native world, I find the lack of swipe-functionality React web packages unbelievable.

I am very appreciative for react-swipeable, as it at least prevents me having to manually manage event listeners, but it's still quite a low-level package in the end, and any meaningful user experience built on react-swipeable will involve a large amount of proprietary code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants