Type-Safe Event Emitter in TypeScript

link管理

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

The Problem

Suppose you want to write a class that emits events. Clients can then install handlers, functions that are notified whenever an event is emitted. Easy enough; in JavaScript, this would look something like the following:

addHandler ( event , handler ) { if ( ! this . handlers [ event ]) { this . handlers [ event ] = [ handler ]; } else { this . handlers [ event ]. push ( handler );

const emitter = new EventEmitter();
emitter.addHandler("start", () => console.log("Started!"));
emitter.addHandler("end", () => console.log("Ended!"));
emitter.emit("end");
emitter.emit("start");

As you probably guessed, we’re going to build on this problem a little bit. In certain situations, you don’t just care that an event occured; you also care about additional event data. For instance, when a number changes, you may want to know the number’s new value. In JavaScript, this is a trivial change:

addHandler ( event , handler ) { if ( ! this . handlers [ event ]) { this . handlers [ event ] = [ handler ]; } else { this . handlers [ event ]. push ( handler );

const emitter = new EventEmitter();
emitter.addHandler("numberChange", n => console.log("New number value is: ", n));
emitter.addHandler("stringChange", s => console.log("New string value is: ", s));
emitter.emit("numberChange", 1);
emitter.emit("stringChange", "3");

The result of this code is once again unsurprising:

New number value is:  1
New string value is:  3
But now, how would one go about encoding this in TypeScript? In particular, what is the
type of a handler? We could, of course, give each handler the type (value: any) => void.
This, however, makes handlers unsafe. We could very easily write:
emitter.addHandler("numberChanged", (value: string) => {
    console.log("String length is", value.length);
emitted.emit("numberChanged", 1);
Which would print out:
String length is undefined
No, I don’t like this. TypeScript is supposed to be all about adding type safety to our code,
and this is not at all type safe. We could do all sorts of weird things! There is a way,
however, to make this use case work.
  The Solution
Let me show you what I came up with:
class EventEmitter<T> {
    private handlers: { [eventName in keyof T]?: ((value: T[eventName]) => void)[] }
    constructor() {
        this.handlers = {}
    emit<K extends keyof T>(event: K, value: T[K]): void {
        this.handlers[event]?.forEach(h => h(value));
    addHandler<K extends keyof T>(event: K, handler: (value: T[K]) => void): void {
        if(!this.handlers[event]) {
            this.handlers[event] = [handler];
        } else {
            this.handlers[event].push(handler);
The important changes are on lines 1, 2, 8, and 12 (highlighted in the above code block).
Let’s go through each one of them step-by-step.
Line 1: Parameterize the EventEmitter by some type T. We will use this type T
to specify the exact kind of events that our EventEmitter will be able to emit and handle.
Specifically, this type will be in the form { event: EventValueType }. For example,
for a mouseClick event, we may write { mouseClick: { x: number, y: number }}.
Line 2: Add a proper type to handlers. This requires several ingredients of its own:
We use index signaturesT; in the preceding example, keyof T would be "mouseClick".

We also limit the values: T[eventName] retrieves the type of the value associated with
key eventName. In the mouse example, this type would be { x: number, y: number }. We require
that a key can only be associated with an array of functions to void, each of which accepts
T[K] as first argument. This is precisely what we want; for example, mouseClick would map to
an array of functions that accept the mouse click location.
Line 8: We restrict the type of emit to only accept values that correspond to the keys
of the type T. We can’t simply write event: keyof T, because this would not give us enough
information to retrieve the type of value: if event is just keyof T,
then value can be any of the values of T. Instead, we use generics; this way, when the
function is called with "mouseClick", the type of K is inferred to also be "mouseClick", which
gives TypeScript enough information to narrow the type of value.
Line 12: We use the exact same trick here as we did on line 8.
Let’s give this a spin with our numberChange/stringChange example from earlier:
const emitter = new EventEmitter<{ numberChange: number, stringChange: string }>();
emitter.addHandler("numberChange", n => console.log("New number value is: ", n));
emitter.addHandler("stringChange", s => console.log("New string value is: ", s));
emitter.emit("numberChange", 1);
emitter.emit("stringChange", "3");
emitter.emit("numberChange", "1");
emitter.emit("stringChange", 3);
The function calls on lines 24 and 25 are correct, but the subsequent two (on lines 26 and 27)
are not, as they attempt to emit the opposite type of the one they’re supposed to. And indeed,
TypeScript complains about only these two lines:
code/typescript-emitter/ts.ts:26:30 - error TS2345: Argument of type 'string' is not assignable to parameter of type 'number'.
26 emitter.emit("numberChange", "1");
code/typescript-emitter/ts.ts:27:30 - error TS2345: Argument of type 'number' is not assignable to parameter of type 'string'.
27 emitter.emit("stringChange", 3);
Found 2 errors.
And there you have it! This approach is now also in use in HydrogenEventEmitter.ts