Type-safe event emitter pattern in Typescript

Introduction

We use a type-safe event emitter to make sure events and their data are correct. This helps avoid mistakes when sending or listening to events.

When building apps that need to send and listen to many different events.

When you want to catch mistakes early by checking event names and data types.

When multiple parts of your program need to talk to each other without being tightly connected.

When you want clear and safe communication between components or modules.

Syntax

Typescript

interface Events {
  eventName: EventDataType;
  anotherEvent: AnotherDataType;
}

class TypedEventEmitter<E> {
  on<K extends keyof E>(eventName: K, listener: (data: E[K]) => void): void {
    // ...implementation
  }
  emit<K extends keyof E>(eventName: K, data: E[K]): void {
    // ...implementation
  }
}

The Events interface defines event names and their data types.

The class uses generics to enforce correct event names and data when calling on and emit.

Examples

This example shows how to listen for a login event with user data, and then emit it.

Typescript

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

const emitter = new TypedEventEmitter<Events>();

emitter.on('login', data => {
  console.log(`User logged in: ${data.user}`);
});

emitter.emit('login', { user: 'Alice' });

Here, the logout event has no data, so we use void and pass undefined when emitting.

Typescript

emitter.on('logout', () => {
  console.log('User logged out');
});

emitter.emit('logout', undefined);

Sample Program

This program creates a type-safe event emitter with two events: message and error. It listens to both and prints messages when events happen.

Typescript

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

class TypedEventEmitter<E> {
  private listeners: { [K in keyof E]?: Array<(data: E[K]) => void> } = {};

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

  emit<K extends keyof E>(eventName: K, data: E[K]): void {
    this.listeners[eventName]?.forEach(listener => listener(data));
  }
}

const emitter = new TypedEventEmitter<Events>();

emitter.on('message', data => {
  console.log(`Message received: ${data.text}`);
});

emitter.on('error', data => {
  console.log(`Error ${data.code}: ${data.message}`);
});

emitter.emit('message', { text: 'Hello, world!' });
emitter.emit('error', { code: 404, message: 'Not found' });

Important Notes

Type safety helps catch errors before running the program.

Always define your event names and data clearly in an interface.

This pattern works well in apps with many events and listeners.

Summary

Type-safe event emitters ensure events and data match expected types.

Use interfaces to list event names and their data types.

This pattern improves code safety and clarity when working with events.

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