Type-safe event emitter pattern in Typescript - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a type-safe event emitter pattern?

It is a way to create an event system where the types of events and their data are checked by TypeScript, preventing errors by ensuring only valid events and data are used.

intermediate

Why use TypeScript generics in a type-safe event emitter?

Generics allow defining a map of event names to their data types, so the emitter knows exactly what data each event carries, enabling compile-time checks.

intermediate

How does the listener function signature look in a type-safe event emitter?

It matches the data type of the event it listens to, for example: (data: EventMap[EventName]) => void, ensuring the listener receives the correct data shape.

beginner

What happens if you try to emit an event with wrong data type in a type-safe event emitter?

TypeScript will show a compile-time error, preventing the code from running until the data matches the expected type for that event.

beginner

Give a simple example of defining an event map for a type-safe event emitter.

Example: type EventMap = { login: { userId: string }; logout: undefined }; This maps 'login' event to an object with userId and 'logout' event with no data.

What does a type-safe event emitter ensure?

A Events can only be strings

B Events run faster

C Only valid event names and data types are used

D Events do not need listeners

Type-safe event emitters check event names and data types at compile time to avoid errors.

In TypeScript, how do you define the types of events and their data for a type-safe emitter?

A Using a generic interface or type mapping event names to data types

B Using any type for all events

C Using string literals only

D Using classes without generics

A generic interface or type maps event names to their data types, enabling type safety.

What is the type of the listener function parameter in a type-safe event emitter?

A Always string

B The data type associated with the event name

C Any type

D Void

The listener receives the exact data type defined for the event, ensuring type safety.

What happens if you emit an event with incorrect data type in a type-safe event emitter?

A The event emits successfully

B The event is ignored silently

C The program crashes at runtime

D TypeScript shows a compile-time error

TypeScript prevents emitting events with wrong data types by showing errors during compilation.

Which TypeScript feature is essential for creating a type-safe event emitter?

A Generics

B Enums

C Type assertions

D Namespaces

Generics allow mapping event names to data types, enabling type safety.

Explain how a type-safe event emitter works and why it is useful.

Think about how TypeScript checks event names and data before running the program.

Describe how you would implement a simple type-safe event emitter in TypeScript.

Start with a type for events, then use generics to enforce types in methods.

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