Why Delegate Events?

Event delegation means putting a single listener on a shared ancestor instead of one listener on every element you care about. The browser does the dispatch for you: the event bubbles up from the element that was actually clicked to the ancestor, and the ancestor's handler runs.

There are two reasons it is worth the extra step. The first is performance. If a list can have a thousand rows, one listener on the container is a thousand times cheaper to register than a thousand listeners on the rows, and it stays that way as the list grows. The second is that it survives changes to the markup. Rows added later work automatically, and rows removed take their listeners with them, so there are no stale handlers pointing at elements that no longer exist.

That second point is the bigger win in practice. The alternative, attaching a listener to every row and removing it when the row is removed, is where memory leaks come from in single page applications.

The cost is that the handler has to work out which element the user actually interacted with. The event object gives you the target, which is the deepest element the event happened on, so clicking the text inside a button reports the text node's parent rather than the button. The standard technique is to use the closest method with a selector, which walks up from the target to the first ancestor that matches, and to check that the match is inside the container you delegated from.

The pattern is one listener on the container, and inside it you find the real target with the closest method. The example below uses a small stand-in for the DOM so that the bubbling behaviour is visible in a plain Node script.

// A tiny stand-in for the DOM, including bubbling.
const element = (tag, attrs = {}) => ({
  tagName: tag.toUpperCase(),
  attributes: attrs,
  children: [],
  listeners: {},
  parentNode: null,
  appendChild(child) { child.parentNode = this; this.children.push(child); return child; },
  addEventListener(type, handler) {
    (this.listeners[type] ||= []).push(handler);
  },
  dispatchEvent(event) {
    // Walk up from the target, firing each ancestor's listeners.
    let node = this;
    const payload = { ...event, target: this };
    while (node) {
      for (const handler of node.listeners[event.type] ?? []) {
        handler({ ...payload, currentTarget: node });
      }
      node = node.parentNode;
    }
  },
});

const list = element("ul", { id: "tasks" });
const item = element("li", { "data-id": "1" });
const label = element("span", { "data-id": "1" });
item.appendChild(label);
list.appendChild(item);

list.addEventListener("click", (event) => {
  console.log("delegated handler saw:", event.currentTarget.tagName);
  console.log("the item id:", event.target.attributes["data-id"]);
});

// The click happens on the span, but the list's handler still runs.
item.children[0].dispatchEvent({ type: "click" });

The mechanism is the bubbling phase. The event starts at the element the user interacted with and travels up through every ancestor, so a listener on the list sees clicks on the list items and on anything inside them. In a real browser the handler would use the closest method to walk up from event.target until it finds the element matching a selector, which is how you find the row that was clicked when the click landed on a nested element.

Two details to get right in production code. Check that the matched element is actually inside the container you delegated from, otherwise a click in a completely different part of the page that happens to match the same selector will trigger your handler. And if you need the browser's default behaviour for some elements, such as a link, check the matched element before you prevent it.