Skip to content
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

throttle/debounce user callback after preventDefault/stopPropagation is executed #3481

Merged
merged 5 commits into from May 11, 2023
Merged

Conversation

hudon
Copy link
Contributor

@hudon hudon commented Mar 23, 2023

This fixes the issue outlined here: #3478

There is a tradeoff worth noting here and perhaps a breaking change. This fix implies that if a user types dragover.prevent.throttle, they do intend the dragover events to all preventDefault(), even the ones that end up not firing the callback because they're getting throttled. If some users however are depending on the current behavior and expecting the entire wrapped callback to be throttled (stopProp/preventDef included), this patch will break their use case. It would be inconsistent behavior, though, to have the event sometimes propagate and sometimes not.

repost of #3479 from feature branch

}
if (modifiers.includes('throttle')) {
let nextModifier = modifiers[modifiers.indexOf('throttle')+1] || 'invalid-wait'
let wait = isNumeric(nextModifier.split('ms')[0]) ? Number(nextModifier.split('ms')[0]) : 250
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't yours, but I think just

Number(nextModifier.replace('ms','')) || 250

would be more efficient and get the same job done.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch, reads better too. I've made the change and confirmed existing tests cover this

@joshhanley
Copy link
Collaborator

@hudon thanks for the PR! Can you revert your last commit? I think that should be changed in a separate PR, that way if we have to revert this PR (or the new PR) if any changes cause issues, then we're not having to revert everything. Thanks!

@hudon
Copy link
Contributor Author

hudon commented Apr 18, 2023

@joshhanley done

@joshhanley
Copy link
Collaborator

@hudon sweet, thanks!

@calebporzio
Copy link
Collaborator

This makes sense to me as a needed fix. Thanks!

@calebporzio calebporzio merged commit c6cee92 into alpinejs:main May 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants