onWheel clamping at boundaries.

[pmndrs]

onWheel clamping at boundaries.

[dbismut]

Hey Matt, thanks for the kind words! Unless there’s something I’m missing, you should use the exact same strategy as for the drag boundaries example, ie clamping the delta and using memo to retain the initial wheel value as you suggested in your last paragraph.

[mpolichette]

Hmm, Maybe I need to build an example.

The issue is that the delta which my handler is called with is not clamped, just the final scroll position.

E.g.

1. You start with 100px below your current position
2. You scroll down 200px, however, the clamp stops you at 100px
3. If you scroll up 100px in the same gesture... what happens?

What I currently see is no motion. The delta my handler gets has gone from 200 to 100, but the whole time we've been clamped at 100px, so nothing has moved.

What I'd like to achieve is, as soon as you start scrolling down, it starts moving again. In this example, you'd be back at your initial position.

Edit: Created a basic example from the current one... Try scrolling the box around a little bit, especially near the boundaries. https://codesandbox.io/s/boundaries-z28ew

[dbismut]

Hadn't seen your edit sorry, well... your example works fine, no? make sure you're actually testing in a new window, as it seems that onWheel events on window don't seem to be triggered properly in the csb iframe.

Btw, here's your csb tweaked using the latest versions of react-use-gesture and react-spring: https://codesandbox.io/s/boundaries-r3dj7

And here is a csb showing that boundaries work properly: https://codesandbox.io/s/react-use-gesture-issue-wheel-n89rq

The left black square shows the clamped y wheel value (boundaries are [-1000,1000]), the right white square shows the unclamped local value.

Btw, this gave me the opportunity to fix a bug in memo, 5.2.4 is now released on npm ;)

EDIT: ok I understand where the issue is after playing with it once more. Wheeling up past the boundaries and then wheeling down doesn't reset memo. I'll find a fix.

EDIT2: now my csb should be working (hopefully!!), I think the code is self explanatory. However, I wonder if the handler shouldn't give xy - previous right away to avoid you making the calculation.

[mpolichette]

Yep, thats exactly the idea! Your solution does what was I was trying to get to!

As for xy-prev I think it would be a decent api to include since the browser scroll event provides an event.deltaXand event.deltaY which are "local to each independent event". When I first started using this library it took me a second to realize that delta was "local to the gesture".

I'm also probably using "local" in a weird way, because local to this library also means a sort of persistent state.

In any case, thank you for your time in helping me. You guys are way too gracious! :)
Feel free to close this issue, unless you want to use it as a holder for including the above api.

[dbismut]

Sure, happy to help, it’s useful to face common problems and in that situation it also allowed me to spot a bug.

Yeah, local and delta concepts were a bit weird to me too (not to mention memo) when I took over the lib, but they really feel natural now.

When you mention the scroll event and deltas I presume you meant the wheel event. That’s true, and actually the lib sums the event deltas so that you’re able to know how much you’ve wheeled, and I do understand the confusion with the lib definition of delta.

But it’s too late to change delta for something else so I’d have to find a new name for the xy-previous delta! If you have any suggestions please shoot and I’ll add it in 5.2.5.

[dbismut]

For info, we’ll rename delta to movement, current - previous will be labeled delta and local is relabeled offset. That will be a breaking change, so planned for v6.