The Observer Pattern in Plain JS

The plain-language idea

The Observer pattern is one object (the subject) keeping a list of interested parties (observers) and notifying all of them when something happens, without knowing anything about who those observers are or what they'll do with the news. The subject just says "this happened" — it never calls a specific observer's specific method by name, and it doesn't hold a permanent, tight reference to any one of them beyond the list.

This is also called pub/sub (publish/subscribe) when the subject and observers are decoupled through an intermediary rather than talking directly — same core idea, slightly different shape. addEventListener, Node's EventEmitter, Redux's store.subscribe, and RxJS observables are all this pattern wearing different clothes.

See it in a real thing: a tiny event emitter

class EventEmitter {
  #listeners = new Map();

  on(event, callback) {
    if (!this.#listeners.has(event)) this.#listeners.set(event, new Set());
    this.#listeners.get(event).add(callback);
    return () => this.#listeners.get(event).delete(callback); // unsubscribe
  }

  emit(event, payload) {
    this.#listeners.get(event)?.forEach((callback) => callback(payload));
  }
}

const cart = new EventEmitter();

const unsubscribe = cart.on("item-added", (item) => {
  console.log(`Added: ${item.name}`);
});

cart.on("item-added", (item) => {
  updateCartBadge(item);
});

cart.emit("item-added", { name: "Keyboard" });
// both listeners run — cart doesn't know or care what either one does

unsubscribe(); // the logging listener stops receiving events

cart never references updateCartBadge or the logging function by name anywhere in its own definition — it only knows "call whatever's registered for item-added." That's the whole point: you can add a third, fourth, tenth listener later, from completely unrelated code, without ever touching EventEmitter itself. The on call returning an unsubscribe function is the other half of a correct implementation — without a way to stop listening, every subscriber leaks for the lifetime of the emitter.

What people usually miss

Watch out

• Forgetting to unsubscribe is the pattern's most common real bug. A subject holds a strong reference to every listener in its list — if a component subscribes and never unsubscribes (say, on unmount), that listener callback, and everything it closes over, stays alive for as long as the subject does. This is a textbook memory leak, not a hypothetical one.
• Observers can't push data back through the same channel. emit is one-directional — the subject broadcasts outward. If an observer needs to talk back to the subject, that's a separate, ordinary function call, not part of this pattern.
• Synchronous by default, and that has real consequences. In the example above, emit calls every listener synchronously, one after another, in registration order. A slow or throwing listener blocks (or breaks) every listener registered after it — production event emitters usually wrap each call in a try/catch specifically because of this.

The genealogy: closures storing state, callbacks doing the notifying

The #listeners map is private state closed over by on and emit — the same closure mechanism from the closures lesson, just used to hold a collection of callbacks instead of one counter or timer. And every callback stored in it is itself an ordinary first-class function being passed around, exactly like debounce's inner function — the observer pattern doesn't need anything the language hasn't already given you.