Type-safe event emitter pattern in Typescript - Step-by-Step Execution

Concept Flow - Type-safe event emitter pattern

Define Event Types

↓

Create Emitter Class

↓

Add Listener with Type

↓

Emit Event with Payload

↓

Listener Receives Typed Payload

↓

Process Event

↓

End

This flow shows how to define event types, create a typed emitter, add listeners, emit events, and handle typed payloads safely.

Execution Sample

Typescript

interface Events {
  login: { user: string };
  logout: {};
}

class TypedEmitter<T> {
  private listeners: { [K in keyof T]?: ((payload: T[K]) => void)[] } = {};

  on<K extends keyof T>(eventName: K, listener: (payload: T[K]) => void): void {
    if (!this.listeners[eventName]) {
      this.listeners[eventName] = [];
    }
    this.listeners[eventName]!.push(listener);
  }

  emit<K extends keyof T>(eventName: K, payload: T[K]): void {
    if (!this.listeners[eventName]) return;
    for (const listener of this.listeners[eventName]!) {
      listener(payload);
    }
  }
}

const emitter = new TypedEmitter<Events>();
emitter.on('login', data => console.log(data.user));
emitter.emit('login', { user: 'Alice' });

This code defines event types, creates a typed emitter, adds a listener for 'login', and emits a 'login' event with a typed payload.

Execution Table

Step	Action	Event Type	Payload	Listener Called	Output
1	Create TypedEmitter instance	-	-	No	-
2	Add listener for 'login'	login	-	No	-
3	Emit 'login' event	login	{ user: 'Alice' }	Yes	Console logs 'Alice'
4	Listener processes payload	login	{ user: 'Alice' }	Yes	Output: Alice
5	No more events	-	-	No	End of execution

💡 No more events to emit, execution ends.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
emitter	undefined	TypedEmitter instance	Listeners for 'login' added	Listeners triggered	TypedEmitter instance
listeners['login']	undefined	undefined	1 listener function	Listener called	1 listener function

Key Moments - 2 Insights

Why does the listener only accept a specific payload shape?

Because the TypedEmitter uses the Events interface to enforce that listeners for 'login' receive exactly { user: string }, as shown in execution_table step 3 and 4.

What happens if we try to emit an event with wrong payload?

TypeScript will show an error before running, preventing emit calls with wrong payload types, ensuring type safety as seen in the code sample.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the listener for 'login' added?

A Step 2

B Step 1

C Step 3

D Step 4

💡 Hint

Check the 'Action' column in execution_table for when listeners are added.

According to variable_tracker, what is the state of listeners['login'] after Step 3?

A No listeners

B Listener called

C Listener function added but not called

D Listeners removed

💡 Hint

Look at the 'After Step 3' column for listeners['login'] in variable_tracker.

If we emit 'logout' event with an empty payload, what will happen?

A Listener for 'login' is called

B Type error because payload is empty

C No listener is called if none registered for 'logout'

D Emit fails silently

💡 Hint

Refer to the concept that listeners are called only if registered for that event type.

Concept Snapshot

Type-safe event emitter pattern in TypeScript:
- Define event types in an interface
- Create TypedEmitter class with generic event map
- Add listeners with .on(event, callback) typed by event
- Emit events with .emit(event, payload) enforcing payload type
- Ensures listeners receive correct payload shape
- Prevents runtime errors by compile-time checks

Full Transcript

This visual execution shows how a type-safe event emitter works in TypeScript. First, we define an interface with event names and their payload types. Then, we create a TypedEmitter instance. We add a listener for the 'login' event that expects a payload with a user string. When we emit the 'login' event with the correct payload, the listener is called and logs the user name. The variable tracker shows how the emitter and listeners change state step by step. Key moments clarify why payload types are enforced and what happens if wrong payloads are used. The quiz tests understanding of listener addition, listener call state, and behavior when emitting events without listeners. This pattern helps catch errors early and keeps event handling safe and clear.

Practice

1. What is the main benefit of using a type-safe event emitter in TypeScript?

easy

A. It makes the code run faster by optimizing event handling.

B. It ensures events and their data match expected types, preventing runtime errors.

C. It automatically logs all emitted events to the console.

D. It allows emitting events without defining their types.

Solution

1. Step 1: Understand type safety in event emitters

   Type-safe event emitters use TypeScript types to ensure events and their data match expected types.

2. Step 2: Identify the benefit of type safety

   This prevents runtime errors by catching mismatches during development, improving code reliability.

3. Final Answer:

   It ensures events and their data match expected types, preventing runtime errors. -> Option B

4. Quick Check:

   Type safety = prevents runtime errors [OK]

Hint: Remember: type-safe means matching event names and data types [OK]

Common Mistakes:

• Thinking it improves runtime speed
• Assuming it logs events automatically
• Believing it allows untyped events

2. Which of the following is the correct way to define an interface for a type-safe event emitter with events login (payload: string) and logout (no payload)?

easy

A. interface Events { login: string; logout: null; }

B. interface Events { login: string; logout: void; }

C. interface Events { login: string; logout: undefined; }

D. interface Events { login: string; logout: never; }

Solution

1. Step 1: Understand event payload types

   Events with no payload should use undefined to indicate no data is expected.

2. Step 2: Check interface options

   interface Events { login: string; logout: undefined; } uses logout: undefined, which correctly represents no payload for the logout event.

3. Final Answer:

   interface Events { login: string; logout: undefined; } -> Option C

4. Quick Check:

   No payload event = undefined type [OK]

Hint: Use 'undefined' type for events with no payload [OK]

Common Mistakes:

• Using void which is a function return type
• Using null which means absence of value
• Using never which means impossible type

3. Given this type-safe event emitter interface and usage:

interface Events {
  message: string;
  error: { code: number; message: string };
}

const emitter = new TypedEmitter<Events>();
emitter.on('message', (msg) => console.log(msg));
emitter.emit('error', { code: 404, message: 'Not found' });

What will be the output when the error event is emitted?

medium

A. No output because no listener for 'error' event is registered.

B. Logs: { code: 404, message: 'Not found' }

C. Throws a type error at runtime.

D. Logs: 'Not found'

Solution

1. Step 1: Check registered event listeners

   Only a listener for 'message' event is registered, no listener for 'error'.

2. Step 2: Understand event emission behavior

   Emitting 'error' without a listener produces no output; no automatic logging occurs.

3. Final Answer:

   No output because no listener for 'error' event is registered. -> Option A

4. Quick Check:

   Emit without listener = no output [OK]

Hint: Only events with listeners produce output [OK]

Common Mistakes:

• Assuming emit logs automatically
• Expecting runtime error without listener
• Confusing event data with console output

4. Consider this code snippet using a type-safe event emitter:

interface Events {
  update: number;
}

const emitter = new TypedEmitter<Events>();
emitter.on('update', (data: string) => {
  console.log(data);
});

What is the problem with this code?

medium

A. There is no problem; the code is correct.

B. The event name 'update' is not defined in the interface.

C. The emitter instance is not created correctly.

D. The listener callback parameter type does not match the event payload type.

Solution

1. Step 1: Check event payload type in interface

   The 'update' event expects a number payload.

2. Step 2: Check listener callback parameter type

   The callback expects a string, which mismatches the expected number.

3. Final Answer:

   The listener callback parameter type does not match the event payload type. -> Option D

4. Quick Check:

   Listener param type must match event payload type [OK]

Hint: Match listener parameter type to event payload type [OK]

Common Mistakes:

• Ignoring type mismatch warnings
• Assuming any type is allowed
• Confusing event names with payload types

5. You want to create a type-safe event emitter for a chat app with events:
- join: payload is username (string)
- leave: payload is username (string)
- message: payload is an object with user (string) and text (string)

Which interface correctly defines these events for type safety?

hard

A. interface ChatEvents { join: string; leave: string; message: { user: string; text: string }; }

B. interface ChatEvents { join: string; leave: string; message: string; }

C. interface ChatEvents { join: { username: string }; leave: { username: string }; message: { user: string; text: string }; }

D. interface ChatEvents { join: string; leave: undefined; message: { user: string; text: string }; }

Solution

1. Step 1: Analyze event payload requirements

   'join' and 'leave' expect a username string; 'message' expects an object with user and text strings.

2. Step 2: Match interface to requirements

   interface ChatEvents { join: string; leave: string; message: { user: string; text: string }; } matches exactly: 'join' and 'leave' as string, 'message' as object with user and text.

3. Final Answer:

   interface ChatEvents { join: string; leave: string; message: { user: string; text: string }; } -> Option A

4. Quick Check:

   Match payload types exactly for type safety [OK]

Hint: Match event names and payload types exactly in interface [OK]

Common Mistakes:

• Using wrong payload types for events
• Omitting required object structure
• Using undefined for events that need payload