DOM Event delegation

DOM event delegation is a mechanism of responding to ui-events via a single common parent rather than each child, through the magic of event "bubbling" (aka event propagation).

When an event is triggered on an element, the
following occurs:

The event is dispatched to its target EventTarget and
any event listeners found there are triggered.Bubbling events will then trigger any additional event listeners found by
following the EventTarget‘s
parent chain upward, checking for any event listeners registered on each successive EventTarget. This upward propagation
will continue up to and including the Document.

Event bubbling provides the foundation for event delegation in browsers. Now you can bind an event handler to a single parent element, and that handler will get executed whenever the event occurs on
any of its child nodes(and any of their children in turn). This is event delegation. Here‘s an example of it in
practice:

<ul onclick="alert(event.type + ‘!‘)">
    <li>One</li>
    <li>Two</li>
    <li>Three</li>
</ul>

With that example if you were to click on any of the child <li> nodes,
you would see an alert of "click!",
even though there is no click handler bound to the <li> you
clicked on. If we bound onclick="..." to
each <li> you
would get the same effect.

So what‘s the benefit?

Imagine you now have a need to dynamically add new <li> items
to the above list via DOM manipulation:

var newLi = document.createElement(‘li‘);
newLi.innerHTML = ‘Four‘;
myUL.appendChild(newLi);

Without using event delegation you would have to "rebind" the "onclick" event
handler to the new <li>element,
in order for it to act the same way as its siblings. With event delegation you don‘t need to do anything. Just add the
new <li> to
the list and you‘re done.

This is absolutely fantastic for web apps with event handlers bound to many elements, where new elements are dynamically created and/or removed in the DOM. With event delegation the number of event bindings can be drastically decreased by moving them to a common
parent element, and code that dynamically creates new elements on the fly can be decoupled from the logic of binding their event handlers.

Another benefit to event delegation is that the total memory footprint used by event listeners goes down (since the number of event bindings go down). It may not make much of a difference to small pages that unload often (i.e. user‘s navigate to different pages
often). But for long-lived applications it can be significant. There are some really difficult-to-track-down situations when elements removed from the DOM still claim memory (i.e. they leak), and often this leaked memory is tied to an event binding. With event
delegation you‘re free to destroy child elements without risk of forgetting to "unbind" their event listeners (since the listener is on the ancestor). These types of memory leaks can then be contained (if not eliminated, which is freaking hard to do sometimes.
IE I‘m looking at you).

Here are some better concrete code examples of event delegation:

• How JavaScript
  Event Delegation Works
• Event
  Delegation versus Event Handling
• jQuery.delegate is
  event delegation + selector specification
• jQuery.on uses
  event delegation when passed a selector as the 2nd parameter
• Event
  delegation without a JavaScript library
• Closures
  vs Event delegation: takes a look at the pros of not converting code to use event delegation
• Interesting approach PPK uncovered for delegating
  the focus and blur events (which
  do not bubble)

DOM Event delegation