Detailed explanation
Event delegation is useful in dynamic lists because it lets a stable parent handle events from its children through one listener. Instead of attaching a click listener to every delete button, you attach one to the table or list container. Buttons inserted later are automatically covered when their events reach that parent. This suits interfaces where rows are frequently added, removed, filtered, or replaced, because you do not need to bind handlers again for each new row.
It works through DOM event propagation. A click normally bubbles from the element that was clicked through its ancestors. Inside the parent’s handler, event.target identifies the original event target, while event.currentTarget identifies the parent holding the listener. In the supplied example, e.target.closest('button[data-del]') finds the matching button even when the user clicks an icon or span inside it. The handler then reads btn.dataset.del and passes that identifier to remove(). Dataset values are strings, so convert or validate the identifier if the removal function expects another type.
The main efficiency benefit is that listener count stays constant for that parent rather than growing with the number of rows. This reduces listener-management work and can reduce memory overhead, but it does not mean total memory usage stays flat: DOM nodes and application data still consume memory. Delegation also separates interaction handling from row creation. However, the parent must remain mounted; replacing the parent element discards its listener, so the listener must be attached again or placed on a longer-lived ancestor.
A robust implementation checks that a matching button exists and belongs to the intended container, commonly using table.contains(btn). With nested lists or tables, an additional ownership check may be needed to exclude controls belonging to an inner component. Delegation also depends on propagation: a descendant calling stopPropagation() can prevent a bubbling listener from running. Not every event bubbles; for delegated focus handling, use focusin/focusout or capture appropriately. Interviewers usually expect you to explain these mechanics and limits, not just say that delegation improves performance.
Key points to remember
- Attach one listener to a stable ancestor instead of one listener per row.
- New descendants work automatically when their matching events propagate to that ancestor.
- Use event.target with closest() to handle clicks on nested content inside a button.
- Listener count remains constant, but total DOM and application memory can still grow.
- Check container ownership and account for parent replacement, non-bubbling events, and stopped propagation.
Common mistakes candidates make
- Checking only event.target.matches('button[data-del]'), which misses clicks on icons or spans inside the button.
- Claiming delegation makes total memory usage constant or is always faster than direct listeners.
- Assuming delegation survives replacing the listener-bearing parent or works with every event unchanged.
Likely follow-up questions
What is the difference between event.target and event.currentTarget?
event.target is the original event target, such as an icon inside a delete button. event.currentTarget is the element whose listener is currently executing, which is the table in this example.
Why use closest() instead of checking the clicked element directly?
closest() checks the element itself and then walks up its ancestors to find a matching control. This handles clicks on nested button content; also verify that the result belongs to the intended container.
Can event delegation handle focus and blur?
focus and blur do not bubble, so a normal bubbling listener on the parent will not receive them from descendants. Use the bubbling focusin and focusout events, or register focus and blur listeners in the capture phase.
Interview tip: Explain bubbling first, walk through the delete-button example, and finish with the stable-parent requirement and one propagation limitation.