Sometime you need to make your code slower to make it faster...
Usually we want our code execute as fast as possible. But in case of DOM events, i...
For further actions, you may consider blocking this person and/or reporting abuse
I'm a big fan of using microtasks for this sort of thing; sometimes they don't provide a long enough delay, but they're a good default tool when you're not entirely sure how much of a delay you need.
In practice, the most common cause I've encountered of repeated event firing is simply that either the same bit of code, or subsequent and/or nested function calls all modify the same bit of state.
This generally means that by the end of the task, we're usually done with the state "for now", and will either be waiting for some asynchronous code to finish, or for new input to respond to.
Another way I've found to work very well for debouncing things like user input is to reset the delay with every new function call; meaning that nothing will happen for as long as new inputs (e.g. keypresses) keep happening, and once the inputs stop or slow down, the page will start working with what it has.
This works well for input because generally speaking, a user that is busy typing something won't care if nothing is immediately happening, but will expect reasonably quick feedback once they stop. For these cases, a resetting delay of ca. 200ms feels to me like a good compromise between responsiveness and random changes while typing, which can feel like an interruption at times.
This is done often, but was exact the reason to think about a different approach. If nothing happens until the user stops typing, this will be a bad experience. Think of a text input device, where you do not see any input until you stop typing...
Using a shorter initial delay makes your app feel responsive, but the repetition might be slower. This is exactly what I wanted to achieve.