DOM event delegation target

Q: DOM event delegation target

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Medium > **How to read this doc:** the entire real point of delegation — that it correctly handles elements added to the DOM AFTER the listener was attached — was verified directly against a real jsdom container, not just asserted as a theoretical benefit. ## 1. The problem, restated Rather than attaching a separate real listener to every individual matching element (which would miss any element added LATER), attach exactly ONE real listener to a stable ANCESTOR container, and use the real, bubbling nature of DOM events plus `Element.closest()` to determine, at event time, whether the actual clicked element (or an ancestor of it, up to the container) matches the target selector. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Must this work for elements added AFTER attaching? | Yes — this is genuinely the entire real reason delegat

The problem

Problem, as an interviewer would state it: "Implement delegate(container, selector, eventType, handler) — attach ONE real listener to container, and have it correctly fire handler only when the actual clicked element matches selector, INCLUDING elements added to the DOM later."

Examples:

Code

delegate(list, "li", "click", (event, target) => console.log(target.textContent));
// works for every <li>, even ones added to the list AFTER this call

Clarifying questions expected:

Should this work correctly for elements added to the DOM AFTER the delegate() call — the whole real reason to use delegation over binding individual listeners?
What if the real click target is a nested element INSIDE a matching one (e.g., an icon inside an <li>)?
Does the handler need access to the actual matched element, not just the raw event?

Code / implementation expected: Yes — real, direct proof against a real DOM: a click on an element added AFTER the listener attached still correctly fires the handler, and a click on a non-matching element does not.

js-coding
utility
algorithm

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for practical JavaScript coding interviews. Difficulty: Medium

How to read this doc: the entire real point of delegation — that it correctly handles elements added to the DOM AFTER the listener was attached — was verified directly against a real jsdom container, not just asserted as a theoretical benefit.

1. The problem, restated

Rather than attaching a separate real listener to every individual matching element (which would miss any element added LATER), attach exactly ONE real listener to a stable ANCESTOR container, and use the real, bubbling nature of DOM events plus Element.closest() to determine, at event time, whether the actual clicked element (or an ancestor of it, up to the container) matches the target selector.

2. Clarifying questions a strong candidate asks

Question	Why it matters
Must th

The solution is hidden so you can try first

6 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct proof: delegation correctly fires for an element that already existed AND one added after attaching, but not for a non-matching element