Architecture Walkthrough

The Data-Action Dispatch Pattern

The naivest delegation implementation checks e.target.matches('.delete-btn'), then e.target.matches('.edit-btn'), and so on for each action. Every new action type adds another condition. A cleaner pattern uses data-action attributes on elements and a dispatch table (a plain object mapping action names to handler functions). The listener becomes generic: find the actionable element, read its data-action, look it up in the dispatch table, and call the handler.

This makes the listener code static. Adding a new action type means adding a handler function to the dispatch table, not modifying the event listener.

Nesting and closest()

In real UIs, action buttons often contain icon elements. A button labeled "Delete" might contain an <svg> icon. When the user clicks the icon, e.target is the <svg>, not the <button>. e.target.matches('[data-action]') returns false and the action is silently ignored.

e.target.closest('[data-action]') solves this by walking up the DOM from wherever the click landed until it finds an element with the data-action attribute. If the click was on an inner <svg>, closest traverses up to the <button> and returns it. If no matching ancestor exists (click on empty space), it returns null, which the early return check handles.

Non-Bubbling Events and Their Bubbling Equivalents

Delegation only works for events that bubble. The commonly needed non-bubbling events and their bubbling alternatives are: focus bubbles as focusin, blur bubbles as focusout, mouseenter bubbles as mouseover (with extra care needed to filter child element transitions), and mouseleave bubbles as mouseout. Always prefer the bubbling version when you need delegation.

Key Code Explained

const container = document.querySelector('.item-list');

// Dispatch table: each action is a named function
const actions = {
  delete(id, item) {
    if (!confirm(`Delete item ${id}?`)) return;
    item.remove();
    syncToServer('DELETE', id);
  },
  edit(id, item) {
    openEditModal(id);
  },
  archive(id, item) {
    item.classList.add('archived');
    syncToServer('ARCHIVE', id);
  },
};

// Single generic listener — no changes needed when new actions are added
container.addEventListener('click', (e) => {
  const target = e.target.closest('[data-action]'); // handles nested icons
  if (!target) return; // click landed on empty space

  const action = target.dataset.action;
  const id = target.dataset.id;
  const item = target.closest('.list-item');

  if (actions[action]) {
    actions[action](id, item);
  }
});

// HTML structure the listener handles:
// <ul class="item-list">
//   <li class="list-item">
//     Item 1
//     <button data-action="edit" data-id="1"><svg>...</svg> Edit</button>
//     <button data-action="delete" data-id="1"><svg>...</svg> Delete</button>
//     <button data-action="archive" data-id="1"><svg>...</svg> Archive</button>
//   </li>
// </ul>

// Delegating focusin for form validation feedback
const form = document.querySelector('#signup-form');

form.addEventListener('focusin', (e) => {
  const field = e.target.closest('[data-validate]');
  if (!field) return;
  field.classList.add('touched'); // trigger CSS validation styles
});

form.addEventListener('focusout', (e) => {
  const field = e.target.closest('[data-validate]');
  if (!field) return;
  validateField(field);
});

// Adding items dynamically — no new listeners needed
function addItem(text, id) {
  const li = document.createElement('li');
  li.className = 'list-item';
  li.innerHTML = `
    ${text}
    <button data-action="edit" data-id="${id}">Edit</button>
    <button data-action="delete" data-id="${id}">Delete</button>
  `;
  container.appendChild(li); // automatically handled by the existing delegated listener
}

The dispatch table approach is the scalability win. The listener code is fixed at three lines of logic regardless of how many action types exist. Compare this to an if/else if chain that grows with every new feature: a 10-action UI would require a 10-branch conditional, all inside the same listener function.

Tradeoffs

What Interviewers Actually Check

• Whether you know the data-action dispatch pattern rather than an if/else chain
• Whether you use closest() rather than matches() to handle nested markup
• Whether you know which events do not bubble and their bubbling alternatives
• Whether you know that delegating to document works but a closer ancestor is preferable
• Whether you can identify when delegation is unnecessary overhead for a static 3-item list

Follow-Up Questions

1. How would you extend the dispatch pattern to support async actions (e.g., confirming with a modal before deleting)?
2. If a delegated listener calls e.stopPropagation(), what is the effect on other delegated listeners higher in the tree?
3. How does Stimulus.js (the Basecamp framework) implement controller-based event delegation differently from the data-action pattern?
4. If a list has 50,000 items, how does delegation compare to direct listeners in terms of memory and initial render time?
5. How would you use a single delegated keyboard listener to implement full keyboard navigation (arrow keys, Enter, Escape) for a dropdown menu?

Common Candidate Mistakes

• Writing a growing if/else chain keyed on CSS selectors rather than using a dispatch table keyed on data attributes
• Using e.target.matches('[data-action]') and having it break when the user clicks an icon inside the button
• Trying to delegate focus and blur events directly and being confused when they never fire on the parent
• Delegating to document for a list inside a modal, causing unnecessary propagation through the entire DOM tree
• Not including an early return when e.target.closest('[data-action]') returns null, causing the action lookup to fail silently or throw

Interview Readiness Checklist

Before you leave this question, make sure you can answer:

• Can you implement a data-action dispatch table that requires no changes to the listener when new actions are added?
• Can you explain why e.target.closest() is preferred over e.target.matches() for nested action elements?
• Can you name the non-bubbling events and their bubbling equivalents?
• Can you explain the memory and lifecycle benefits of delegation for a dynamically rendered list?
• Can you identify when delegation adds unnecessary complexity for a static small list?

Summary

Event delegation places one listener on a parent and uses event bubbling to intercept events from descendants. The basic pattern filters by e.target.closest('[data-action]') to find the nearest actionable ancestor and dispatches to a handler via a lookup table keyed on data-action attribute values. This design keeps the listener code static regardless of how many action types the UI supports.

The dispatch table pattern is the scalability key. New actions require a new entry in the table only. The listener itself never changes. Delegated listeners also work automatically for dynamically added elements because the listener is on the parent, not the items.

focus and blur do not bubble. Use focusin and focusout for delegation of focus events. For mouseenter and mouseleave, use mouseover and mouseout with careful filtering of events originating from child element transitions.