Event Delegation with jQuery

This is the last in a series of posts on bubbling, delegation and how to delegate events with jQuery. You should already have read the articles What does event bubbling mean and Event Delegation in JavaScript, or have a grasp on their topics.

Event Delegation with jQuery

At the end of the last post, we had a table with hundreds of rows. Each row contained a <a /> to which we wanted to attach a click handler to. We added a single handler to the <table/> element (we delegated the event handler to it) to capture the event.

The correct way to delegate an event handler to the <table> for a click on the <a /> in jQuery would be;

$('#the-table').on('click', 'a', function (e) {
    alert('You clicked row #' + $(this).closest('tr').prop('rowIndex')); 

    e.preventDefault();
});

See it in action here. In words, we capture the element we wish to delegate the event to ($('#the-table')) and call the on() method on it. The event type is the first parameter (click), and the second parameter is a selector which pinpoints the descendant(s) we wish to handle events for (a). The third parameter is the event handler.

Inside the event handler, this is the element the event occurred on (e.g. the <a /> that was clicked). Inside the Event object;

  1. e.target is the element the event occurred on (the same value as this).
  2. e.delegateTarget is the element the event is delegated to (the <table /> element).

Note that jQuery has the same caveat as normal JavaScript when delegating an event to an element; the element you’re delegating to (the table in this case) must exist in the DOM at the time you attach the event.

Controlling Event Bubbling with jQuery

A developer can prevent an event bubbling any further up the list of ancestors if they want to.

To do this, call the stopPropagation() on the event object passed to an event handler. This will execute all other event handlers bound to the current element, but will not propagate up the DOM. You can see this in action here. Even though we’ve bound a click handler to all elements in the ancestor chain, you only see alerts for the a, span and h1, as the h1 handler prevents the event bubbling further.

stopImmediatePropagation() will also prevent the event propagating, but it’ll also stop any other event handlers bound to the current element from firing.

You can check whether an event’s had it’s propagation stopped via the isPropagationStopped() method and isImmediatePropagationStopped() methods.

Another way a developer can stop the event propagating is by returning false from an event handler. This is equivilant to calling stopPropagation() and preventDefault(). I personally recommend against using this shortcut, as it’s use can cause confusion; instead use the methods themselves to make your code more meaningful.

Event Delegation in JavaScript

This is the second post in a series on bubbling, delegation and how to delegate events with jQuery. It assumes you’ve already read the first post What does event bubbling mean, or already have a grasp on event bubbling in JavaScript.

Event Delegation

When providing examples, I’m going to refer to the HTML we used as an example in the first post (shown below):

<div>
    <h1>
        <a href="#">
            <span>Hello</span>
        </a>
    </h1>
</div>

Also note that I’m still not interested in adding support to older versions of IE (<9). You’ll have to add the normal fallback to attachEvent instead of addEventListener if you want to support them, and find an alternative for querySelector/ querySelectorAll. The event target property exists as srcTarget in older versions of IE.

So now we understand event bubbling… but how does it help us?

It means if we want to add an event handler for a click on the <span> element in the above example, we don’t need to add it to the <span> element; we can add it to any of it’s ancestors… as shown here;

window.addEventListener('load', function () {
    document.querySelector('div').addEventListener('click', function (e) {
        if (e.target.nodeName === "SPAN") {
            alert('Click event fired on the SPAN element'); 
        }
    }, false);
});

But yes, I hear you ask me again… how does this help us?

Imagine you have a table with hundreds of rows. Each row contains a <a /> to which you want to attach a click handler to. With no event-bubbling you’d have to bind the event handler to each <a />; which involves iterating over each element and adding an event handler individually to each one. See it in action here. Does it feel efficient to you?;

window.addEventListener('load', function () {
    // Add loads of rows
    var rows = '';

    for (var i = 0; i < 100; i++) {
        rows += '<tr><td>' + i + '</td><td><a href="#">Click Here</a></td></tr>';
    }

    document.querySelector("table").innerHTML = rows;
    // End setup

    // Attach event to each element
    var elements = document.querySelectorAll('#the-table a');

    for (var i=0;i<elements.length;i++) {
        elements[i].addEventListener('click', function (e) {
            alert('You clicked row #' + this.parentNode.previousSibling.innerText);
        }, false);
    };

    alert('Event handler bound to ' + elements.length + ' elements');
});

Instead, what we could do is bind one click handler to the <table />.

document.querySelector('#the-table').addEventListener('click', function (e) {
    if (e.target.nodeName === "A") {
        alert('You clicked row #' + e.target.parentNode.previousSibling.innerText);
    }
});

See this in action here.

Secondly, imagine you load some content dynamically and you want some capture some events on it. You can only add event handlers to elements once they exist (makes sense right?), so without event-bubbling you’d have to re-bind the same event handlers to your content each time you add the content.You can see this in an example here, where we add rows to the table programmatically when you click a button.

However, because the <table /> element does exist in the DOM when the page is rendered, we can add an event handler to this no problem, as shown here. This is a common problem when loading elements via AJAX as well; and attaching the event handler to an element that is in the DOM from the page load is the solution.

So in summary, you should be taking advantage of event bubbling by using event delegation if you want to handle an event for multiple elements, or you want to bind events to dynamically loaded data.

Now move onto the next article; Event Delegation with jQuery

What does “event bubbling” mean?

“Delegation” and “bubbling” are terms that gets thrown round a lot in JavaScript; but what exactly do these terms mean?

This is the first in a series of posts on bubbling, delegation and how to delegate events with jQuery; What does event bubbling mean, Event Delegation in JavaScript and Event Delegation with jQuery

Event Bubbling

In JavaScript, events bubble. This means that an event propagates through the ancestors of the element the event fired on. Lets show what this means using the HTML markup below;

<div>
    <h1>
        <a href="#">
            <span>Hello</span>
        </a>
    </h1>
</div>

Lets assume we click the span, which causes a click event to be fired on the span; nothing revolutionary so far. However, the event then propagates (or bubbles) to the parent of the span (the <a>), and a click event is fired on that. This process repeats for the next parent (or ancestor) up to the document element.

You can see this in action here. Click “Hello” and see the events as they get fired. The code used is shown below;

window.addEventListener("load", function () {
    var els = document.querySelectorAll("*");

    for (var i = 0; i < els.length; i++) {
        els[i].addEventListener("click", function () {
            alert('Click event fired on the ' + this.nodeName + ' element');
        });
    }
});

Note that I’m not interested in adding support to older versions of IE (<9). You’ll have to add the normal fallback to attachEvent instead of addEventListener if you want to support them, and find an alternative for querySelectorquerySelectorAll.

That’s all event bubbling is; an event fired on an element bubbles through its ancestor chain (i.e. the event is also fired on those elements). It’s important to note that this isn’t a jQuery feature, nor is it something that a developer must turn on; it’s a fundamental part of JavaScript that has always existed.

Ok, that’s a little bit of a lie… sort of.

By default, not all events bubble. For instance submit does not normally bubble, nor does change. However, jQuery masks this in the event handling code using all sorts of voodoo, so it will seem that they do bubble when using jQuery.

Now move onto the next article; Event Delegation in JavaScript

Converting to `on()`

jQuery 1.7 introduced new methods for handling DOM events in JavaScript; on() and off(). In this article we will focus on on().

It is intended that, from now on, on() should be used where you’d previously have used any of bind(), live(), delegate(). In particular, live() has been depreciated already; so usage of this in your projects should cease immediately. Converting from any of these methods to on() is easy; you just have to follow the following conversion rules:

  1. If you were previously using bind(), simply change the function name to on(); on() supports the same method signatures as bind().

    $('.foo').bind('click', function () { 
        alert('Hello'); 
    })`;
    

    … will now be…

    $('.foo').on('click', function () { 
        alert('Hello'); 
    });
    
  2. If you were previously using delegate(selector, map), where selector identified the elements whose events you wanted to handle, and map was an object which mapped event types to handlers, swap the selector and map arguments around.

    $('div').delegate('a', {
        mouseover: function () {
            alert('Mouse Over!')'            
        },
        mouseleave: function () {
            alert('Mouse Out!')'
        }
    }); 
    

    … will now be…

    $('div').on({
        mouseover: function () {
            alert('Mouse Over!')'            
        },
        mouseleave: function () {
            alert('Mouse Out!')'
        }
    }, 'a'); 
    
  3. All other uses of delegate() can be converted to on() by swapping the order of the first two parameters (the selector and event list)

    $('div').delegate('a', 'click', function () { 
        alert('Clicked!'); 
    });
    

    … will now be…

    $('div').on('click', 'a', function () {
        alert('Clicked!');
    });
    
  4. All uses of live() can be converted to use on() by inserting the selector as the second argument to on(), and setting what-used-to-be-the-selector to document:

    $('a').live('click', function () { 
        alert('Clicked!'); 
    });
    

    … will now be…

    $(document).on('click', 'a', function () {
        alert('Clicked!');
    });
    

.. and that’s all there is to it! To find out more about the new function on(), you can read it’s extensive documentation on the jQuery website.

live() vs bind() vs delegate()

Introduction

When you wish to attach an event handler in jQuery, you find yourself with no less than three ways of doing so; the bind(), live() and delegate() methods. Methods such as click(), change(), blur() and their various friends fall under the bind() category, as they simply invoke bind() behind the scenes, as does one().

The following blog post outlines the differences between each method, which should help you to decide which method to use in which scenario.

The deal breaker

The most important behavioural difference to remember between the three methods is how they handle elements which would match the given selector , but are not yet in the DOM; the bind() method quite literally iterates over each element matched by the selector and attaches an event handler to it. Because of this, it will only attach the event handler to elements that are currently in the DOM. Both the live() and delegate() methods work differently however, and this variation in functionality ensures the handler will fire for all current and future elements in the DOM. Because of this, you cannot use bind() if some of the elements you wish to attach handlers for are not in the DOM at the time you attach the handler. You must use either live() or delegate() in this scenario.

So how do live() and delegate() work? Can they look into the future?

Not quite. They both utilize a powerful feature of JavaScript called event bubbling (you might have heard it being called event propagation). Event bubbling is not complicated; it merely ensures that an event will bubble (or propagate) through all the ancestors of the element the event occurred on until either:

This means that an event that occurs on an element can be captured and handled by any of its ancestors; for example, a table can capture any event which occurs on any of it cell’s. Both live() and delegate() exploit this behaviour and attach an event handler to an element which is:

  • Registered in the DOM at the time the event handler is bound.
  • An ancestor of the target elements, so that the event reaches it.

live() always attaches the event handler to the document element, whereas delegate() allows you to specify which element is chosen. It is probably worth a mention at this point that without jQuery, some events would not bubble at all, and other events bubble only in some browsers; however jQuery performs work behind the scenes to fix this behaviour.

That’s cool, but I’m here to find out when to choose live() over delegate()

The bottom line is that neither has a major advantage over the other. delegate() is often seen as having an advantage over live() for the following reasons:

  • delegate() allows the developer to choose where the handler is bound to; live() always binds the handler to the document. This allows the developer to minimise the amount of ancestors the event has to bubble through before the handler is found; which lessens the chances of an element preventing the propagation of the event.
  • To call live(), you first need to construct a jQuery object of the elements that currently match the selector. However with delegate() this is not the case. It is unusual (although not unheard of) for this jQuery object to be needed; i.e. a waste of computation.

Just to complicate things: another reason not to use bind()

As touched upon earlier, bind() will attach an event handler to every element matched by the selector. If your selector matches 100 elements, 100 event handlers will be added. However, delegate() and live() attach only one event handler, no matter how many elements your selector matches. No doubt you can see the performance advantage already, and you can see that if you want to attach an event handler to number of elements, delegate or live should be chosen over bind.

So a quick and easy to remember summary?

Some of the elements I want to attach the event to will be added to the DOM at a later time (e.g. programmatically/ via AJAX/ another event handler)

You cannot use bind(); use delegate() or live().

I will be attaching the handler to a number of elements

Consider using delegate() or live() over bind()

I only need the elements to attach the handler to them; I don’t need them for anything else (e.g. you won’t be adding classes/ changing attributes)

Consider using delegate() over bind() and live()