Closes issue #58

[Siutan]

Closes #58

Changes made:

• Adjusted handleDragging() function to check for distance dragged.
• Added dragThreshold variable to set the intensity of the drag effect (Default is 50).
• Added tapped variable to check if distance of drag < threshold.

Notes:

dragThreshold is exported and can be used like:

<Fullpage dragThreshold={100}>
    ...
</Fullpage>

The quick way to fix this is also to do the following in FullpageController.svelte:

const handleDragEnd = () => {
        const hasScrolledUp = dragStartScroll > fullpage.scrollTop - 1 // append - 1 to offset the tap, thus disabling scroll
    ...
}

I was unsure if this would bring up more issues/outliers later, so I didn't implement it this way.
I also found it easier to implement the sensitivity (dragThreshold) using the handleDragging() function as opposed to the above fix.

[Hejtmus]

Generally I like it, but I don't like introducing demanding calculations. The other solution you have suggested did the trick, but I could reproduce the bug when rapidly dragging and then clicking. So I actually think this is better solution, if you could somehow simplify tat threshold calculation, it would be great. But if that's over your time limit, I can accept your other solution as temporary fix, and later fix it properly. Thanks for PR!

[Hejtmus]

Looks fine, but could you explain, why did you pick 50 as default value?

[Siutan]

50 felt the most natural when swiping. But that was my personal preference and other users might want something different so I exported it so users can choose.

[Hejtmus]

Well, I like that you are thinking of people that would like to customize this, but I think that something that distinguishes whether is something tap or swipe should be deterministic and not adjustable. It shouldn't be like some concrete event is on one page tap and on another swipe.

[Hejtmus]

I think here is too much math done for event that's fired every time user drags. Especially division is pretty demanding, it would be fine to mitigate it.

[Siutan]

Maybe we can improve the performance by using squared distances as opposed to absolutes, for example:

const distance = Math.pow(event.clientY - dragPosition, 2);
const threshold = Math.pow(fullpage.clientHeight / dragThreshold, 2);
const isDrag = distance > threshold;

This way we can avoid the square root calculation involved in computing the actual distances. The side-effect of this is maybe a few edge cases where user inputs are wrongly identified.

Another option is to use bitwise operations, an example would be:

const distance= (event.clientY - dragPosition) ** 2;
const threshold = (fullpage.clientHeight / dragThreshold) ** 2;
const isDrag = distance > threshold;

This optimization works because its only interested in whether one distance is greater than another, and you don't need the actual values; however, I believe the performance gain opposed to this will not be significant as this is not a large enough calculation to warrant it.

[Hejtmus]

Thanks for trying for optimization,
but I meant so meting different, like changing semantics of dragThreshold to entirely mitigate division. Actually calculating squared distances would not speed up calculations as it is defined not by power and root, but rather as negation of negative value, and you can see it in V8 code. And FYI '**' operator is actually not bitwise operator, but just expressive writing of power.

[Hejtmus]

If you'll be committing some code from code review, please use conventional commits, sorry for not mentioning it in project contribution guidelines.

[Hejtmus]

Now I'm starting to not like this solution, it's over complicated and it could pollute code, which will require breaking change to clean (I mean that export of DragThreshold). When I was working on version 1.0.0, I was trying to minimize number of needed exports props needed for customization, but to keep level of customization high. Adding prop for decision whether something is tap or drag is overkill, and I thing it is generally decidable with simple heuristic.
I admire you will to fix this bug, and also your time investment, but I don't think this solution should be merged. I'd rather merge that other 1 line heuristic fix for now, and later, when I'll have time, I'll address this issue. Currently I'm busy to experiment with ways of fixing this, but please, keep this PR open, if I later find out, this is the best solution, so you cold heave credit on this. Please could you create another PR with that other solution?

Thank you very much,
Filip.

[Hejtmus]

Thanks for trying for optimization,
but I meant so meting different, like changing semantics of dragThreshold to entirely mitigate division. Actually calculating squared distances would not speed up calculations as it is defined not by power and root, but rather as negation of negative value, and you can see it in V8 code. And FYI '**' operator is actually not bitwise operator, but just expressive writing of power.

[Hejtmus]

Well, I like that you are thinking of people that would like to customize this, but I think that something that distinguishes whether is something tap or swipe should be deterministic and not adjustable. It shouldn't be like some concrete event is on one page tap and on another swipe.

[Siutan]

Okay, thank you for giving me a better understanding both on the direction of this library and on the v8 implementation. I will create a new pull request for the other solution when I have time this week.
Thank you,
Mukil

[Hejtmus]

Hi @Siutan,
today I'll be committing some code to this lib, if you are busy and you want, I can commit your other solution and tag you as co-author, so you won't lose your credit. I can wait with release for your answer.

Best,
Filip.

[Siutan]

Hi @Hejtmus,

Please go ahead and include the change with your commit, unfortunately I have not had time to work on it.

Thanks,
Mukil

[Hejtmus]

Now I found special edge case in that one line solution, that scrolls up any section, that is below other section and doesn't have slides, so I have to find another solution to #58. Hopefully next week I have had finished work for my clients, so I can figure out solution with no side effects.
Thanks again for report and your will and patience to fix #58, I will inform you about state of the issue.

Have a nice day,
Filip.