As development in Javascript moves further away from rollovers and other simple effects into developing true Rich Internet Applications, the number of events we have on our pages increases seemingly exponentially. Catch a left click, a right click, focus, blur, etc.--we're constantly pushing the boundaries of the Javascript event model. Through all of this, one aspect of Javascript events very often gets overlooked: event bubbling and it's power for enabling event delegation.
Reading the specification is often overly complicated, so I will summarize. Event Bubbling specifies that a Javascript event will not only register for the actual element on which the event occurred, but on all of that elements ancestors all the way up to document. For example say we have a form with a text box and we want to perform some action when a user clicks on the text box:
<form onclick="handleClick()">
<fieldset>
<input id="bubbleexample" type="text" />
</fieldset>
</form>
Notice that our event handler has been set on the form and not on the text box itself. When the text box is clicked, the event generated will first be called on the text box itself. Then it will move up to the fieldset. Next it will hit the form element. It will continue to affect each ancestor element until it reaches the root element (document). This is called event bubbling.
Notice also that we are handling that event on the form element and not on the the text box itself. This is called event delegation.
You may, at this point, be asking yourself: what's the advantage of this technique? In the case above where we are only looking at a single event, there is no advantage. However, as the number of event handlers on your page grows, you can see significant performance increase both in terms of processing time and memory use. A complete discussion as to the exact reasons why is beyond the scope of this tutorial; but the important aspects are:
- The event handler only has to be applied to one element (reduces processing time)
- Only one copy of the event handler will reside in memory (reduces memory consumption)
In this example, I've applied event handlers using event delegation, and included metrics regarding processing time differences between using delegation and adding an event handler to each item individually.
There is, of course, a caveat to using event delegation: events you had no intention to handle will likely need to be handled gracefully by your handlers. Notice on line 12, of the example, the event handler checks to make sure it is not acting on the parent container; only the elements within that container. Obviously, as the DOM becomes more complicated beneath your chosen delegator element, so too will become the handler that must check what element it is being called on.
That said, the benefits do outweigh this potential pitfall. As you'll notice the code for the handler itself merely determines which element it was called on, checks that the element qualifies for action, and passes the element to another function which performs the actual action. This is good architecture; as the code to determine what to do with a particular event grows and multiple paths become possible, your code will be much easier to read and work with when you separate the actual action from the event handling.
So there you have it; a very brief introduction to using event delegation and its advantage over the more traditional paradigm.
