If you’ve read any of my posts you might have seen the pattern I like to use for using event delegation. That pattern, in its simplest form, looks like this:

   $(document).ready({
      $('body').on('click','div',changeSomething);

      function changeSomething(e){
         // do something
      }
   });

For me this is super useful – I can dynamically add elements to the DOM and not need to worry about attaching event listeners to specific UI elements. Well, as you can see I have the click event mapped to div elements. This works fine for something as simple as this:

<div>hello world</div>
<div>the sky is blue</div>

If I click with div my changeSomething event will fire. If that’s what I wanted to happen then this is working perfectly. But what happens when we introduce more complicated layout with nested div‘s?

<div>
  <div>hello world</div>
  <div>the sky is blue</div>
</div>

Each time I click on either line **2** events are fired and my function will be fired twice. Consider this layout:

<div>
  <div>
    <p>hello world</p>
    <div class="button">I'm a button</div>
  </div>
  <div>
    <p>the sky is blue</p>
    <div class="button">I'm another button</div>
  </div>
</div>

If I clicked the “button” divs you will see that **3** events are fired for each click. Why would this be?

First, lets understand how event delegation works.

Event delegation relies on event bubbling. Event bubbling is the behavior that describes how events “bubble up” through the DOM. That is, they start at the DOM element where it was initiated and then travel up to that element’s parent, and then up to the parent’s parent, etc., until the event is stopped somehow (via the event.stopPropogation() method) or it reaches the top level DOM element (body).

Event bubbling is key to delegating events – notice that I bound the click event to the body – this means that my code is waiting for “click’s” to “bubble” their way up to the body. If they didn’t bubble through the DOM then the event listener I created would never “hear” the event.

While this explains why it is possible to delegate events it doesn’t explain why when using jQuery to create event listeners that we “hear” multiple events each time we click on a div one single time. This bit from the jQuery documentation provides the answer:


jQuery bubbles the event from the event target up to the element where the handler is attached (i.e., innermost to outermost element) and runs the handler for any elements along that path matching the selector.

Note that the docs says “…and runs the handler for any elements along that path matching the selector. Therein lies the answer. jQuery is firing our callback handler for each element that matches the selector that I passed to the jQuery “on” method. Meanwhile the event is bubbling through the DOM – through other div elements – which causes the callback handler to fire again and again. Each time the handler is fired it receives the very same event object.

Now that we understand what is happening we can look at our HTML and know that this structure:

<div> <<< event #1 bubbles up to here and event #3 is created
  <div> <<< event #1 bubbles here and event #2 is created
    <p>hello world</p>
    <div class="button">I'm a button</div> <<< click here to create event #1
  </div>
</div>

…will cause our callback handler to fire 3 times from a single event instead of firing only once.

How do we prevent this from happening? Well…. we dont. jQuery behaves the way it behaves, but we can write a small bit of code to prevent a single event from firing our functions multiple times. There are plugins that address this – called “debouncing” plugins – sure you can go ahead and use one as they are great for those who don’t understand why things happen and just want things fixed. But I just explained why things happen **and** this article isn’t called “Debouncing Delegated Events in jQuery” for nothing ๐Ÿ˜‰

Recall that each handler call is passed the event object which will be the same for them all. If you log those events to the console you will see that they all have the same timestamp since, quite naturally, they are in fact identical. With this knowledge we can build a “debouncer”.

Review the following (its very much simplified for this example):

   $(document).ready({

      var _fifo = []; // used by the debouncer

      // debounce
      function _isOriginal(e){
        for (var i=0;i<fifo.length;i++){
          if (_fifo[i] === e.timeStamp){
            return false;
          }
        }
        _fifo.push(e.timeStamp);
        if (_fifo.length > 20){
          _fifo.splice(0,1);
        }
        return true;
      }

      // create event listener
      $('body').on('click','div',changeSomething);

      // the callback for the delegated "click" event
      function changeSomething(e){
        // check the event to see if we have already seen it!
        if (!_isOriginal(e)){
            return; // if we ***have*** already seen the event then ignore it!
        }
        // do stuff in here
      }
   });

Pay attention to the _isOriginal function. It does the following:

  • Uses the _fifo array to store the 20 most recent timestamps
  • Compares the timestamp of the current event against those stored within the _fifo array
  • If there is a match it returns “false” (ignore the event)
  • If there is no match it returns “true” (new event!)
  • Timestamps are cycled in and out of the _fifo array at all times so that we will always have a timestamp from the most recent event and thus will always be able to compare and reject copies. The last/oldest timestamp is pruned (via the splice method ) from the _fifo array once its length hits 20 while the newest is added to the front (read about FIFO stacks)

(incidentally, the “20” number was an arbitrary selection ๐Ÿ™‚ )

There you go, a simple and effective debouncer. Toss those plugins aside and reduce your dependency list! You often don’t need plugins if you understand the reasons why people created them to begin with!