-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Bug: onStop returns wrong positions when using grid #413
Comments
Any update on whether anyone is looking into this? I'm experiencing this as well. Dragging to a grid is effectively broken as you can't guarantee that it will stay on that grid. |
For anybody who is also experiencing this, I've found an okay workaround.
While users can still end a drag in the incorrect position, the view will immediately update after to the proper position. |
Had the same issue and @jeffkillian's solution worked for me (though I'm not sure why this isn't the default behavior)! |
Thanks for the report. I see two ways we can fix this:
2 is cleaner but I am not 100% sure it will not have side effects. Looking into it. |
This was caused by `onStop` erroneously recalculating coordinates, which is not necessary / should not happen in the real world, as `mouseup` and `touchend` should not pass `clientX` and `clientY` values meaningfully different than the last corresponding move event. In fact, they are already ignored by `<Draggable>`. For this reason, we can simply trust the `lastX` and `lastY` in `onDragStop`, and pass those back. Fixes #413, bokuweb/react-rnd#453
any updates on this? |
When using grid, the x and y returned by onStop are incorrect. lastX and lastY however seem to be correct. I can't find a explanation for the values onStop returns for x and y.
I've created an example showing the behavior:
https://codesandbox.io/s/texthighlights-wtrzt
Please have a look at the console output when dragging the object around. I would have expected x and y to change based on the grid of [50,50] but this is not the case.
React-draggable is also used by react-rnd - they also have an issue open for this bug (bokuweb/react-rnd#453)
The text was updated successfully, but these errors were encountered: