Open fabyeah opened 1 year ago
Please provide a demo, reading code is way too consuming for me as a maintainer.
When the drag starts there's no reason why you would have a direction right from the start since it's a mouse down. The only case is when using the threshold / filterTaps options but even then it's debatable whether the first drag event should have a direction at all.
Sandbox: https://codesandbox.io/s/focused-shannon-2s2j93
Try moving cards left and right lots of times, eventually you'll get some [0, 0]
console logs.
Apparently when you add the drag
config to useGesture
, then onDragStart
stops firing on mouse down, but waits until you move the mouse. So you should always get the direction and you do most of the time, but sometimes it doesn't work even though internally with _direction
it is logged correctly. So not sure if this is an error, but feels like it?
I have more or less the same scenario. I am in bounds
. And when i try resize an element, if I console.log(state)
I see direction: [0,0] and _direction: [-1,0].
Now if i try to console.log(state._direction)
or do const { _direction } = state;
I get [0,0].
@fabyeah sorry for the late reply. i don't have any [0, 0]
logs, but ok fair enough, I'll see if there's anything I can do here. Here's the rationale anyway so that it's clear what's going on. If you use useDrag
without any of the options axis, lock, filterTaps, threshold
the handler will fire on pointerdown
.
However, when you use one of the options aforementioned, the lib waits until you've made enough movement so that it can determine whether the drag matches the option. Here the example you sent over uses the axis: 'x'
option. Which means useDrag
will wait until the user has made enough movement along the x
axis before firing the handler. If it wasn't doing this, you would be also receiving events for a drag along the y
axis, which is not something you want.
Internally, the DragEngine uses some _
prefixed variables so that it still knows what's going on, but the actual gesture only begins when active
becomes true. So it is possible that the direction is [0, 0]
when the drag becomes actually active. But I agree that if we know the direction at this point, we might as well pass it along.
In hindsight and after looking through the code I hardly see why you would get state.direction equal to [0, 0] when a movement has been made. In fact, I can't even reproduce this. The direction is calculated through the delta, which itself is calculated from the offset, which is calculated from movement. To clarify, would you be able to show me a video showing the logs on your browser? I'd like to clarify something. Thanks.
Does this also happen outside of an iframe with the actual browser console?
Yes, I opened this issue because it happened in my project.
Happens with both trackpad and mouse?
Only tried with mouse and with finger on mobile device until now. Tried with trackpad now and seems like the problem doesn't occur there.
Interesting. Thanks for your input. I'll have a look this week end if I can.
Describe the bug Same as #32, When dragging, sometimes (when starting the drag fast?) the direction in
onDragStart
is [0,0] instead of [1,0] or [-1,0].Here is a log of the
state
var fromonDragStart
when it happens:So
direction
is [0,0], but_direction
is [-1,0]. I will switch to using that variable for now, hopefully without problems. There was an x value logged, so not sure why it doesn't set direction correctly.Information:
Checklist:
touch-action: none
to the draggable element.