What is the click event's type and how to reference the button?
DOM event inheritance and currentTarget versus target.
Handler receives a MouseEvent. Use event.currentTarget for the attached button, since event.target may be a nested child.
What's really being asked
This question tests two separate but related concepts in the DOM event model. The first is type specificity within the event inheritance chain. The second is the distinction between event.target and event.currentTarget, which separates the element that dispatched the event from the element that registered the listener. Senior interviewers care about this because confusing the two leads to delegation bugs and brittle event handling.
The full answer
A strong answer states that the handler receives a MouseEvent, not merely Event or UIEvent. It notes the inheritance chain: MouseEvent extends UIEvent, which extends Event. For the button reference, the answer should name event.currentTarget as the reliable property, explaining that it refers to the element on which the listener was registered. It should contrast this with event.target, which identifies the deepest element actually clicked and can differ when the button contains nested children like icons or spans. It may also mention that in TypeScript, the handler should be typed as (event: MouseEvent) => void or use a proper generic with addEventListener to avoid implicit any. Mentioning event.currentTarget may require a type assertion in TypeScript since it is typed as EventTarget | null, so casting to HTMLButtonElement is common practice.
The mistakes people make
Answering Event or UIEvent instead of MouseEvent shows shallow knowledge of the event hierarchy. Recommending event.target as the way to get the button is a frequent mistake that breaks when the button contains child elements. Suggesting this is also risky because this depends on how the function is invoked and can be undefined in arrow functions or strict mode. Another red flag is claiming currentTarget and target are always identical, which ignores event bubbling and nested DOM structures.
What usually comes next
The interviewer may ask how event delegation changes the answer, where the listener is on a parent but you need the specific button that was clicked. They might ask about TypeScript typing challenges with event.currentTarget and why it is not automatically narrowed to HTMLButtonElement. They could also ask about the MouseEvent properties available, such as clientX, clientY, or button, and when you would use PointerEvent instead.
A concrete example
Imagine a button containing an SVG icon. A user clicks directly on the icon. The event.target is the SVG path element, while event.currentTarget is the button element. If your handler relies on event.target to toggle a class on the button, it will incorrectly toggle the SVG instead. Using event.currentTarget ensures you always manipulate the button regardless of where the click lands inside it.
Interview question
A button containing a nested span is clicked. If the listener is attached to the button, what is the event type and which property reliably references the button?
- a.It is a UIEvent; use event.target to reference the button.
- b.It is a MouseEvent; use event.target to reference the button.
- c.It is a MouseEvent; use event.currentTarget to reference the button.Correct
- d.It is an Event; use this to reference the button.
Why? this is the answer
The click handler receives a MouseEvent, and event.currentTarget always refers to the element that owns the listener, whereas event.target points to the actual nested element clicked—such as the span—so it would fail to reference the button itself.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #typescript
- #dom
- #events
- #mouseevent
- #web-apis
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on typescript — each one lists the topics its interview covers.
See open roles