Where does it make the most sense to debounce events? Consider the resize event of an internet browser. The browser can fire a myriad of resize events as a user clicks and drags to resize a browser window. However, usually, you end up debouncing handling the resize event listener callback because you usually only care about the start or end of a resize action.

If I had some functionality that would fire events in a similar, burst manner, would it make sense to debounce firing my event from my emitter or does it make more sense to send out all the events, no matter how many, and let the consumers themselves deal with debouncing?

I would consider the benefit of debouncing from the source to be that you don't have to have multiple debouncers littering your code everywhere that you consume your own events so less code duplication. However, I see the benefit of debouncing at the listener level to be that you get a much higher resolution of source events in case you need that and you get more control over tweaking the delay in the debounce per listener.

  • But when you send the start and end of a resize only, how could a user see the contents of the window during the resize process? Though I switched that off, some users insist on that. Commented May 10, 2017 at 8:57
  • How could you detect the start and end of a resizing? Combine it with mouse button down/up? In this case you can only do it on the sender side, where in my opinion it belongs anyway. Commented May 10, 2017 at 20:22

2 Answers 2


I'd say that the consumer should take care of that. This way the emitter does not need to make any assumptions about how the consumer wants to handle the event. Maybe in a very defined context, where the emitter and the consumer is controlled by you, you can do it the other way around. But even in that case I'd stay with the option that implies less guessing about the needs of the consumer.

  • 1
    I would just provide both event types, Resize (which is triggered continuously) and ResizeStart, ResizeEnd, so that the user can decide which to subscribe to. Commented May 10, 2017 at 20:20
  • Matter of fact, that is a very good idea.
    – Zalomon
    Commented May 11, 2017 at 7:23

In a system with first class "channels" or "event streams", debouncing is a separable concern e.g. in Reactive Extensions. In this context, the code that should be doing it should be the code that wires up the consumer and producer, neither themselves worrying about debouncing.

If this isn't an option then you have to make a choice. Zalomon is completely correct that the more flexible and future-proof option is for the consumer to do the debouncing. However, this comes at the cost of duplicate code and duplicate work plus the mental load of needing to remember to do it if it is a common or even ubiquitous requirement. If it is very unlikely that anyone would want the "raw" event stream and/or there are significant performance consequences a bunch of events that are ultimately ignored, it may well make a lot more sense to do the debouncing at the event producer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.