DOM and Browser APIs

## What the pattern actually is Event delegation is a wiring decision, not an API. Instead of registering a handler on every element a user can interact with, you register one handler on an element that contains them all, and inside that handler you determine which descendant the interaction concerned. For a to-do list the listener goes on the `<ul>`; for a data grid, on the `<tbody>` or the wrapping `<div>`; for a toolbar, on the toolbar element itself. ```js const list = document.querySelector('#todos'); list.addEventListener('click', (event) => { const item = event.target.closest('li[data-id]'); if (!item || !list.contains(item)) return; console.log('activated item', item.dataset.id); }); ``` That is the whole idiom: one registration, one guard, one dispatch. Everything else — how many rows exist, when they were created, how often they are replaced — is irrelevant to the wiring. ## Why items added later are covered The listener is a property of the container, not of its children. When you append a new `<li>`, you create a node your setup code has never touched — and it does not need to be touched, because the element observing the interaction is still the container, and the container was wired once at startup. The event object handed to your handler carries a reference to the innermost element the interaction landed on, so the handler can identify the new row even though it did not exist when the handler was written. The practical consequence is a separation of duties. The code that renders rows becomes a pure "produce DOM" function with no knowledge that rows are clickable; the code that defines behaviour sits in one place next to the container. Removing a row is symmetric: it takes no per-row wiring away with it, because there was none. ## Identifying the right child The naive check `event.target.tagName === 'LI'` is fragile, because the interaction usually lands on something *inside* the row — a `<span>`, an icon, a nested `<button>`. `Element.prototype.closest(selector)` walks from the element upwards and returns the first ancestor-or-self that matches, which is exactly the mapping you want: "given whatever was hit, which row is it in?" `Element.prototype.matches(selector)` is the exact-match variant when you know the interaction lands directly on the element. Two guards are worth having by default. First, `closest()` returns `null` when nothing matches, so a delegated handler that acts on the result unguarded throws on interactions with the container's own padding. Second, `closest()` does not stop at your container — in nested lists it can return a row belonging to an outer list, so `container.contains(row)` keeps the dispatch honest. A common refinement is to mark rows and controls with a data attribute and dispatch on it: `event.target.closest('[data-action]')` plus a lookup table keyed by `dataset.action`. That turns a growing `if/else` chain into a flat map of behaviours and makes the markup declare what each control does. ## Where to attach the listener Pick the nearest ancestor that outlives the children. `document` works but is coarse: every such listener participates in every interaction on the page, and one careless handler can affect unrelated widgets. A listener registered on a container dies with that container, so if your update code replaces the container wholesale rather than emptying it, the wiring disappears with it — attach one level up, on the element that never gets replaced. ## What it costs and when to skip it Delegation trades per-element setup for per-event lookup: one registration and one short ancestor walk per interaction, instead of N registrations and none. For a list of five static buttons that never change, per-element handlers are simpler and the tradeoff is not worth reasoning about. Delegation earns its place when the set of children is large, changes often, or is produced by code that should not have to know about behaviour at all.