Episode 1 — Fundamentals / 1.15 — Event Handling in JavaScript
Interview Questions: Event Handling in JavaScript
Model answers for addEventListener, bubbling / capture, target vs currentTarget, forms & preventDefault, classList, and lifecycle / scroll performance.
How to use this material (instructions)
- Read lessons —
README.md→1.15.a–1.15.e. - Practice out loud — 1–2 minutes per question.
- Exercises —
1.15-Exercise-Questions.md. - Quick revision —
1.15-Quick-Revision.md.
Beginner (Q1–Q4)
Q1. What is event bubbling?
Why interviewers ask: Foundation for delegation and debugging “why did my parent handler run?”
Model answer:
After the browser dispatches an event on the target element, most DOM events propagate upward through ancestors in the bubble phase unless stopped. Parent elements with click listeners will see the event after the child unless stopPropagation was called. This enables event delegation: one listener on a parent inspects event.target to handle clicks on many children.
Q2. Explain event.target vs event.currentTarget.
Why interviewers ask: Delegation bugs are common when these are confused.
Model answer:
event.target is the innermost element where the event originated (e.g. the <span> clicked inside a button). event.currentTarget is the element the listener is attached to — the one you called addEventListener on. In delegation on <ul>, currentTarget is the list while target might be a specific <li> or interactive child.
Q3. When do you use preventDefault on a form?
Why interviewers ask: SPA / AJAX patterns and accessibility of validation.
Model answer:
Call preventDefault() on the form’s submit event when you want to stop the browser’s default navigation (full page POST/GET) and instead handle submission in JS — e.g. fetch, client-side routing, or custom validation flow. Without it, the browser performs a normal document navigation based on action and method. Still validate on the server — client validation is UX, not security.
Q4. What is the difference between DOMContentLoaded and load?
Why interviewers ask: Race conditions in boot code and “why is my image width 0?”
Model answer:
DOMContentLoaded fires when the HTML is parsed and the DOM is available — it does not wait for images/stylesheets to fully finish. load on window fires when the page and its dependent resources (as defined by the spec for that document) have loaded — better for code that needs dimensions of images or all assets ready. DOMContentLoaded typically fires first.
Intermediate (Q5–Q8)
Q5. How does event capturing differ from bubbling?
Why interviewers ask: Shows you understand full event flow, not only defaults.
Model answer:
DOM events travel down from window through ancestors to the target (capture phase), then hit the target, then travel up (bubble phase). addEventListener defaults to bubble phase. Pass { capture: true } to run on the way down — useful for intercepting before children or library wrappers. stopPropagation stops further propagation in the current phase chain; stopImmediatePropagation also blocks other listeners on the same element.
Q6. Why might passive: true matter for scroll or touchmove listeners?
Why interviewers ask: Scroll jank and mobile performance are common topics.
Model answer:
passive: true tells the browser the listener will not call preventDefault(), so the main thread need not block scrolling waiting for your listener to decide. For scroll / touch listeners that only read position or update lightweight UI, passive improves responsiveness. If you must prevent default (e.g. custom swipe), you cannot use passive for that listener.
Q7. Why prefer addEventListener over element.onclick = fn?
Why interviewers ask: Multiple handlers, memory leaks, and testability.
Model answer:
onclick property allows only one handler — assignments overwrite previous handlers. addEventListener supports multiple listeners, works with named functions for removal, and aligns with separation of concerns (JS modules attach behavior). Inline onclick="..." attributes mix concerns and complicate CSP — avoid in production apps.
Q8. What is strict mode and one thing it fixes?
Why interviewers ask: Baseline JS discipline; modules are strict.
Model answer:
'use strict' enables the strict mode dialect. Among other rules, assigning to an undeclared variable throws ReferenceError instead of accidentally creating a global variable in sloppy mode. ES modules are strict by default. It also changes this behavior in some function call patterns — important when reading older code.
Advanced (Q9–Q10)
Q9. Describe event delegation and one trade-off.
Why interviewers ask: Performance and dynamic lists (infinite scroll, tables).
Model answer:
Delegation attaches one listener on a stable ancestor (e.g. <tbody>) and uses event.target (often with closest("tr")) to handle events for many descendants, including nodes added later. Pros: fewer listeners, no re-bind on DOM churn. Cons: logic can become harder to read; you must handle edge cases (clicks on whitespace, nested controls); closest has a small cost vs direct binding — usually negligible.
Q10. input vs change for <input type="text"> — which fires more often and why?
Why interviewers ask: Form UX and debouncing search boxes.
Model answer:
input fires on every value change as the user types — ideal for live validation, character counts, and typeahead (often debounced for network). change for text inputs typically fires when the control loses focus after the value changed — better for “committed” values. Using input without throttling for expensive work can hurt performance.
Quick-fire
| # | Question | One-line |
|---|---|---|
| 1 | Stop link navigation | preventDefault() on click |
| 2 | Listener runs once | { once: true } |
| 3 | toggle force off | classList.toggle("x", false) |
| 4 | Read all form fields for fetch | new FormData(form) |
← Back to 1.15 — Event Handling (README)