This repository has been archived by the owner on Oct 8, 2021. It is now read-only.
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #2015 from mlitwin/bug_1992
Fixes #1992; Swipe threshold constants are configurable
- Loading branch information
Showing
1 changed file
with
12 additions
and
4 deletions.
There are no files selected for viewing
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
7b1966c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've had some difficulty understanding the documentation and source code on this and tried illustration so that we could talk about it to each other, we're still not sure if we have it right though. So far it has been a trial and error process. Would love some feedback from any of the contributors on this.
In essence our understanding is that the swipe must break out of the box created by horizontalDistanceThreshold and verticalDistanceThreshold in a horizontal manner. And to scroll there can't be horizontal movement wider than the scrollSupressionThreshold. Is this a correct english interpretation of the math?
7b1966c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jbergantine
Basically what the code is trying to say is that if the following constraints were satisfied:
then a left/right swipe event is triggered.
In my opinion the scrollSupressionThreshold is un-necessary, and should be removed such that we always prevent the scroll. The reason I say this is because the threshold is 10px which is the same magic number that iOS and Android use to trigger/initiate scrolling. If we don't want scrolling, then we should just preventDefault on every touchmove event.
7b1966c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! We were pretty close then I guess. scrollSupressionThreshold seems a bit weird still (we're using a number of 100 on that for an app that navigates between long scrolling pages via swipe where most people in our user testing want to be scrolling down the page not swiping on any given movement).
7b1966c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After thinking about this a bit more, I think we only want to supress scrolling if the user's touch has not exceeded the vertical threshold. Once they exceed this, then we should allow scrolling. This will allow folks to use swipe on longer pages.
7b1966c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW this is the configuration we're currently using:
We found the defaults way to prone to cause a swipe instead of a scroll. Additionally, when people got to the bottom of a long scroll the page had a tendency to "jump" to the next page which seemed to be a result of their fingers staying on the page etc.