Q013: DOM Events and Event Delegation

What Interviewers Want To Evaluate

This question tests whether you understand how user interactions travel through the DOM. Interviewers want to hear about event targets, current targets, capturing, bubbling, default actions, propagation control, passive listeners, and event delegation.

For senior roles, the practical signal is whether you can use this knowledge to build scalable UI, debug broken interactions, avoid memory leaks, improve performance, and reason about framework event systems such as React's synthetic events.

Short Interview Answer

DOM events represent interactions or browser signals such as clicks, input, keyboard events, scroll, focus, and network-related events. When an event happens, it has a target and travels through phases: capture from the root down, target phase, and bubble back up if the event bubbles. Event delegation attaches one listener to a common ancestor and uses event.target or closest to handle events from child elements. This reduces listener count and works well for dynamic lists, but it requires careful selector checks, accessibility awareness, and understanding which events bubble.

Detailed Interview Answer

When a user clicks a button, the browser creates an event object. The event path usually starts from the document root, moves down through ancestors during capture, reaches the target, and then bubbles back up through ancestors. Listeners can run during capture or bubble depending on how they are registered.

event.target is the original element that triggered the event. event.currentTarget is the element whose listener is currently running. This distinction matters in delegated handlers because the listener may be attached to a parent while the actual target is a child.

Event delegation is useful when many child elements share the same interaction. Instead of attaching one listener to every row in a large table, attach one listener to the table container and inspect the event target. This is usually simpler for dynamic lists because new children do not need new listeners.

Deep Technical Explanation

The event flow is:

Window / Document
  -> capture phase down ancestors
  -> target phase
  -> bubble phase up ancestors

Delegation works because bubbling lets a parent observe events from descendants. The parent can decide whether the event is relevant.

Internal Working

The browser computes an event path. It invokes listeners registered for capture first, then listeners on the target, then bubble listeners if the event bubbles. stopPropagation prevents the event from continuing to other nodes in the path. preventDefault cancels the browser's default action when the event is cancelable, such as following a link or submitting a form.

Some events do not bubble in the way people expect. focus and blur do not bubble, though focusin and focusout do. Shadow DOM can also change event visibility through composed events and retargeting.

Architecture Discussion

Event architecture matters in complex frontend applications. A page with thousands of rows, menus, cells, and controls should not blindly register thousands of independent listeners when a delegated design would be simpler. But delegation should not become one giant global handler with unclear ownership.

In React, events are usually handled through React's event system, but the DOM model still matters. React event handlers receive synthetic events that normalize behavior, while native listeners may still be needed for document-level interactions, portals, integrations, and low-level performance work.

Trade-Offs

Delegation reduces listener count and handles dynamic children well. It can also make logic less local, especially when selectors become complex. Direct listeners are easier to understand for isolated components. Capture-phase listeners are useful for global interception, but they can make debugging harder if overused.

The right choice depends on DOM size, component ownership, dynamic behavior, and event type.

Common Mistakes

A common mistake is confusing target and currentTarget. Another is assuming all events bubble. Another is using stopPropagation as a quick fix, which can break parent components, analytics, menus, or accessibility behavior.

A senior answer should also avoid treating click handlers as the whole story. Keyboard events, focus, pointer events, touch, scroll, and default browser behavior matter for accessible applications.

Real Production Story

A dropdown may close immediately after opening because a document click listener sees the same click that opened it. The fix requires understanding event order, propagation, and whether the close listener should run on capture, defer to the next task, or check whether the click happened inside the dropdown.

The bug is not random UI behavior. It is event flow.

Enterprise Example

In a permissions matrix with thousands of cells, direct listeners on every checkbox and icon can increase memory and setup cost. A delegated handler on the grid can handle cell actions based on data attributes. The implementation still needs keyboard accessibility, focus management, and clear ownership between row, cell, and menu interactions.

Code Example

const list = document.querySelector("[data-user-list]");

list?.addEventListener("click", (event) => {
  const target = event.target;

  if (!(target instanceof Element)) {
    return;
  }

  const button = target.closest("[data-action]");

  if (!button || !list.contains(button)) {
    return;
  }

  const action = button.getAttribute("data-action");
  const userId = button.getAttribute("data-user-id");

  console.log({ action, userId });
});

This delegates click handling to the list container while still checking that the matching element belongs to the intended container.

Performance Discussion

Delegation can reduce listener registration cost and memory usage in large dynamic UIs. Passive listeners can improve scroll performance by telling the browser that the handler will not call preventDefault. Heavy event handlers can still create long tasks, so delegation is not a substitute for efficient interaction logic.

Security Considerations

Delegated handlers often read attributes from DOM nodes. Treat user-generated DOM content carefully. Do not use event data to build unsafe HTML or execute dynamic code. In complex apps, avoid broad document-level handlers that accidentally trust interactions from untrusted embedded content.

Scalability Discussion

As UI grows, event ownership needs structure. Use delegation for repeated dynamic surfaces, direct handlers for local component interactions, and central document listeners only for cross-cutting behavior such as escape key handling or outside-click detection.

Senior Engineer Perspective

A senior engineer should explain event flow and then describe how it affects real UI: dropdowns, modals, tables, menus, keyboard accessibility, analytics, and memory leaks.

Lead Engineer Perspective

A lead engineer should define interaction standards: keyboard support, passive scroll listeners, cleanup rules, outside-click patterns, and when delegation is preferred for large lists.

Whiteboard Explanation

Draw a nested DOM tree. Mark the clicked child as the target. Show capture going down and bubbling going up. Then attach a listener to the parent and explain how it handles child actions through event.target.closest.

Revision Notes

Events have target and currentTarget. Many events capture and bubble. Delegation attaches a listener to an ancestor and handles descendant events. preventDefault cancels browser behavior; stopPropagation stops event travel.

Key Takeaways

Event delegation is a scalability pattern for interactions. It works because many DOM events bubble, but it must be used with careful target checks and accessibility awareness.

Related Topics

• DOM and CSSOM
• Event loop
• React synthetic events
• Accessibility
• Passive listeners
• Shadow DOM
• Memory leaks

Practice Exercise

Use the JavaScript practice ground to build a delegated click handler for a list of buttons. Log target, currentTarget, and the selected action. Then explain how the behavior changes if you call stopPropagation.

Follow-Up Questions

1. What is event bubbling?
2. What is event capture?
3. What is the difference between target and currentTarget?
4. What is event delegation?
5. Which events do not bubble normally?
6. When would you use capture phase?
7. Why can stopPropagation be dangerous?
8. What does preventDefault do?
9. What are passive listeners?
10. How does React's event system relate to DOM events?

Things Interviewers Hate Hearing

"Event delegation is faster" is too vague. Explain that it reduces listener count and handles dynamic children, but it still needs efficient handlers and clear ownership.

How I Would Answer This In A Real Interview

I would say DOM events travel through phases: capture down the tree, target, and bubble back up when the event supports bubbling. event.target is where the event originated, while event.currentTarget is the element whose listener is currently running. Event delegation uses that bubbling behavior to attach one listener to a parent and handle actions from child elements.

Then I would connect it to production. Delegation is useful for large dynamic lists and grids, but I would be careful with selectors, non-bubbling events, keyboard accessibility, and stopPropagation. For complex apps, event architecture is about ownership and predictable interaction flow, not just reducing listeners.