Where should event debouncing be done, in the emitter or consumer?

Question

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.

Answer 1

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.

Answer 2

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.