Skip to content
tezvyn:

currentTarget vs. target: Who's Listening vs. Who Shouted

Source: developer.mozilla.orgHardHow cards are made

currentTarget vs. target: Who's Listening vs. Who Shouted

event.currentTarget is the element listening for an event, while event.target is the element that triggered it. This is vital for event delegation patterns. Be careful: currentTarget is only valid inside the handler and becomes null afterward.

Why it exists

To distinguish between the element an event handler is registered on and the actual element that triggered the event. This separation is necessary to support event bubbling and delegation, where a single parent listener can handle events from many descendants without attaching a listener to each one.

The mental model

Think of event.currentTarget as "the listener" and event.target as "the source." An event, like a click, originates at the target element. It then "bubbles" up the DOM tree. If it encounters an ancestor element that is listening for that event, that ancestor becomes the currentTarget for that phase of event handling. The currentTarget is always the element you wrote .addEventListener() on.

How it works

When an event is dispatched, the browser identifies the deepest element in the DOM tree that was the event's origin—this is event.target. The event then propagates up the DOM tree from parent to parent. If any of these ancestors have a listener for this event type, their handler is invoked. Inside that handler, event.currentTarget will refer to that ancestor element itself. The value of target remains constant throughout this bubbling phase, always pointing to the original element.

When to use it

Use currentTarget when you have a generic handler on a parent and need a stable reference to that parent, regardless of which child was clicked. This is the core of the event delegation pattern. For example, a listener on a <ul> can handle clicks on any <li> by checking event.target, but it might use event.currentTarget to access properties of the <ul> itself. Use target when you need to know exactly which descendant element initiated the event.

When not to use it

The biggest footgun is relying on currentTarget outside the synchronous execution of the event handler. Its value is reset to null once the handler's call stack frame is popped. If you need to reference the element in an asynchronous callback, like a fetch().then() or setTimeout(), you must store event.currentTarget in a local variable first.

One canonical example

Imagine a parent with id="parent" containing a child with id="child". An event listener is attached only to the parent: parent.addEventListener('click', handler). If you click directly on the child , inside the handler function, event.target will be the child and event.currentTarget will be the parent . If you click the parent but miss the child, both event.target and event.currentTarget will be the parent .

Interview question

A developer logs event.currentTarget inside a setTimeout callback initiated within an event handler. Why might this log null?

  • a.The event object itself is garbage collected once the initial event propagation finishes.
  • b.The element referred to by currentTarget was removed from the DOM before the setTimeout executed.
  • c.event.currentTarget is only valid during the synchronous execution of the event handler.Correct
  • d.The event listener was attached using the capture phase, which completes before the timeout.
Why?

event.currentTarget is a live reference that is reset to null once the event handler's synchronous execution completes and its call stack frame is popped. This occurs regardless of whether the element is still in the DOM or if the entire event object has been garbage collected.

Just read this? Test yourself on what you have been reading.

Read the original → developer.mozilla.org

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.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on dom — each one lists the topics its interview covers.

See open roles