MediumFrontend6 min read

Implement EventEmitter (on/off/once/emit) — Node style

Q: Implement EventEmitter (on/off/once/emit) — Node style

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Medium > **How to read this doc:** the trickiest real claim — that a listener calling `off()` on itself WHILE `emit` is still iterating does not corrupt iteration or skip a later, still-registered listener — was verified directly, not just assumed safe. ## 1. The problem, restated An `EventEmitter` maintains, per event name, a list of listener functions. `on` registers one; `off` removes a specific one; `once` registers one that auto-removes itself after firing exactly once; `emit` synchronously calls every currently-registered listener for that event, in registration order, with the given arguments. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Self-removal mid-emit handled safely? | A real, genuine correctness hazard if the listener array is mutated WHILE being iterated directly. | | Can `once()` be removed via `off()` before f

1.1k views

82 of 154

The problem

Problem, as an interviewer would state it: "Implement a Node-style EventEmitter class with on(event, fn), off(event, fn), once(event, fn), and emit(event, ...args)."

Examples:

Code

const emitter = new EventEmitter();
emitter.on("data", (x) => console.log("got", x));
emitter.emit("data", 42); // "got 42"

Clarifying questions expected:

If a listener calls off() on itself (or another listener) WHILE emit is iterating, should that be handled safely?
Does once() need to also support being manually removed via off() before it ever fires?
Should emit() return a boolean indicating whether any listeners existed, matching Node's own real convention?

Code / implementation expected: Yes — real, direct proof of all 4 core methods, including the subtlest case: a self-removing listener executing mid-emit.

event-emitter
pubsub

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for practical JavaScript coding interviews. Difficulty: Medium

How to read this doc: the trickiest real claim — that a listener calling off() on itself WHILE emit is still iterating does not corrupt iteration or skip a later, still-registered listener — was verified directly, not just assumed safe.

1. The problem, restated

An EventEmitter maintains, per event name, a list of listener functions. on registers one; off removes a specific one; once registers one that auto-removes itself after firing exactly once; emit synchronously calls every currently-registered listener for that event, in registration order, with the given arguments.

2. Clarifying questions a strong candidate asks

Question	Why it matters
Self-removal mid-emit handled safely?	A real, genuine correctness hazard if the liste

The solution is hidden so you can try first

6 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct proof: EventEmitter correctly handles on/off/once, and a listener removing itself mid-emit does not break other listeners

Practice

Discussion

Other approaches, follow-ups and how it went in real interviews.

No comments yet. Share how you would answer it.

Question 82 of 154 in JavaScript coding

Keep your momentum going.

Mark this question solved to track your progress, then take the next one while it is fresh.

All JavaScript coding questions

Up nextMedium→

Implement a Memoized Selector That Only Recomputes When Its Specific Inputs Change (Reselect-Style)

Continue