-
Couldn't load subscription status.
- Fork 83
debounce events #27
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
base: release/1.0.0
Are you sure you want to change the base?
debounce events #27
Conversation
|
Thanks, nice work. I'll take a closer look at this tomorrow. |
|
Haven't forgotten about this. |
|
I'm getting some really peculiar behavior when I test this. Regular events that shouldn't be debounced are firing at strange times, and the events that should be debounced ( Are you not seeing this behavior when you test it? |
|
Apologies, you're 100% correct. Thanks for the feedback, I clearly wasn't thinking properly. As far as I can tell, the events are now firing roughly correctly. There is still an issue with drag-over styling in the demo app, which I'm unsure how to handle, maybe you can advise: in Now, because the dragover events are being debounced, they might end up firing after a "dragleave" event, which means the dragover styling is applied and then not removed. There are two options:
I prefer option 1, since the dragover event can be pretty noisy |
|
I appreciate your continued effort on this. I haven't tested your new commit yet, but I would say that any event that can be debounced should have the option to not be debounced at all—meaning its dispatch function should be called directly, not wrapped in any sort of debounce decorator. There are going to be times when users need the complete flow of rapidly fired drag/dragover events, and forcing them through a debounce wrapper unconditionally is going to render certain use cases impossible to implement. When I originally started to take a crack at this, I used a |
|
Yea, agreed about making it configurable. I wanted to do it initially (see my initial comment), but only now have an idea of how to sensibly implement it. Will update the PR at some point this week |
|
@cameronhimself @ckritzinger Hey guys, is this PR still active? I need this change :) |
|
We ended up running into way too many cross-browser issues from relying on HTML5 drag. So we wrote our own implementation (that looks more like the Jquery version). If I get around to packaging that as a vue plugin, I'll let you know. |
|
@sbward This feature isn't particularly high on my priority list. If someone else would like to pick it back up before I get to it I'd be happy to work with them, of course. |

Ideally, I would have liked to let the debounce time to be passed to the component as a property, but I'm still a bit of a n00b with Vue, so I wasn't able to get that bit right (the properties are not available at the time when the debounced function is created)
Other than that, it seems to work mostly as I would expect.
Apologies if the code is crappy, I'm still on the steep part of the JS/Vue learning curve. Happy to incorporate stylistic/design changes if you suggest any.