Observer & pub/sub

Let many parts of an app react to one change

Apps often need several things to happen after one change. Say a shopper adds a book to the cart. Then:

• the header shows the new number of items,
• analytics, the code that records what shoppers do, notes the book,
• storage saves the cart, so it is still there after a page reload.

The easy way is to make the cart code do all three jobs itself. That works. But then the cart code has to know about every job. This lesson shows better ways.

All of them use the same idea. One piece of code says "something changed." Other pieces of code ask to be told. Those are called listeners. A listener is just a function that waits to be called. Code also calls listeners observers, subscribers, or handlers. In this lesson, these four words mean the same thing.

The table below puts the five tools side by side. Read each row as: "this tool works like this, and here is a tiny example." Some words are new; each one is explained in its own section.

This lesson uses ideas from earlier lessons: callbacks, closures, events, and custom events. The functors & monads lesson built a tiny observable. The memory management lesson explains why forgotten listeners waste memory.

Two pieces of code are tightly coupled when one has to know the other by name and call it directly. Here is a cart update that is tightly coupled to three other jobs.

1const cart = [];2 3function updateCart(item) {4  cart.push(item);5  renderHeader(cart.length);6  trackAnalytics(item);7  saveCart(cart);8}9 10function renderHeader(count) {11  console.log(`header ${count}`);12}13function trackAnalytics(item) {14  console.log(`analytics ${item}`);15}16function saveCart(items) {17  console.log(`saved ${items.join(",")}`);18}19 20updateCart("book");

Line 4 adds the item to the cart. Line 5 updates the header. Line 6 tells analytics. Line 7 saves the cart. Line 20 calls updateCart("book"). The console shows header 1, analytics book, and saved book.

So updateCart has four jobs, not one. Each new job means changing it again. And to test the cart, you also need the header, analytics, and storage code.

In the observer pattern, the subject has a subscribe function. To subscribe means to join the list. You pass in a listener function, and the subject adds it to its list.

subscribe gives back another function. Call that one later to leave the list. Leaving the list is called unsubscribing.

The code below keeps the list in a Set. A Set is a collection that holds each value only once. It also remembers the order you added them in.

1const listeners = new Set();2function subscribe(listener) {3  listeners.add(listener);4  return () => listeners.delete(listener);5}6const stopHeader = subscribe((item) => console.log(`header ${item}`));7subscribe((item) => console.log(`storage ${item}`));8for (const listener of [...listeners]) listener("tea");9stopHeader();10console.log(listeners.size);

• Lines 2 to 5 make subscribe. Line 3 adds the listener to the set. Line 4 returns a small function that deletes that same listener.
• Line 6 subscribes the header listener. It keeps the leave function in stopHeader. Line 7 subscribes the storage listener.
• Line 8 calls every listener with "tea". The header joined first, so it prints header tea first. Then storage prints storage tea.
• Line 9 calls stopHeader(), which removes the header. Line 10 prints 1, because only storage is left.

On line 8, [...listeners] copies the set into a new array before the loop starts. You'll see why that copy matters in a moment.

A subject in a real app needs two safety steps:

• Copy the list before calling anyone, with [...observers]. Then a listener that leaves halfway through doesn't change the loop that is running.
• Catch an error from one listener, so the next listeners still run. try/catch does this. If code inside try throws an error, JavaScript jumps to catch instead of stopping.

Step through the example below. Watch the storage listener remove itself during the first call to notify.

1function createSubject(name) {2  const observers = new Set();3  return {4    subscribe(observer) {5      observers.add(observer);6      return () => observers.delete(observer);7    },8    notify(value) {9      for (const observer of [...observers]) {10        try {11          observer(value);12        } catch (error) {13          console.log(`${name} isolated ${error.message}`);14        }15      }16    },17    count() {18      return observers.size;19    },20  };21}22 23const cart = createSubject("cart");Run24let stopStorage;25cart.subscribe((item) => console.log(`header ${item}`));26cart.subscribe(() => { throw new Error("analytics offline"); });27stopStorage = cart.subscribe((item) => {28  console.log(`storage ${item}`);29  stopStorage();30});31cart.notify("book");32cart.notify("pen");33console.log(`subscribers ${cart.count()}`);

Here is the order. The header runs. Analytics throws an error, and the catch prints it. Storage still runs, and then removes itself. The second notify reaches only the header and analytics. This works because of the copied list and the try/catch around each listener.

Next, one listener removes a different listener while the subject is calling everyone.

1const listeners = new Set();2function subscribe(listener) {3  listeners.add(listener);4  return () => listeners.delete(listener);5}6let stopStorage = () => {};7subscribe((item) => {8  console.log(`header ${item}`);9  if (item === "first") stopStorage();10});11stopStorage = subscribe((item) => console.log(`storage ${item}`));12function notify(value) {13  for (const listener of [...listeners]) listener(value);14}15notify("first");16notify("second");17console.log(listeners.size);

Line 13 copies the set before it calls anyone. On the first call, line 15, the header runs first. Line 9 then removes storage from the set. But the copy already has storage in it, so storage still prints storage first.

On the second call, line 16, a new copy is made without storage. So only header second prints. Line 17 prints 1.

1const observers = [2  () => console.log("header updated"),3  () => { throw new Error("offline"); },4  () => console.log("storage saved"),5];6for (const observer of [...observers]) {7  try {8    observer();9  } catch (error) {10    console.log(`reported ${error.message}`);11  }12}

Line 3 is a listener that throws an error with the message offline. The try/catch on lines 7 to 11 sits inside the loop, around each single call. So line 10 prints reported offline, and the loop moves on. The last listener still prints storage saved.

Pub/sub goes one step further than observer. The code that announces a change is called the publisher. In pub/sub, the publisher doesn't keep a list at all. A third object, the bus, keeps the lists. (Some code calls the bus a broker.)

• Each list in the bus has a name, called a topic, such as cart:changed.
• Listeners subscribe to a topic.
• The publisher gives the bus a topic and some data. That data is called the payload.

1const cart = { observers: new Set() };2cart.observers.add((item) => console.log(`observer ${item}`));3for (const observer of cart.observers) observer("tea");4 5const broker = new Map();6broker.set("cart:changed", [(item) => console.log(`pub/sub ${item}`)]);7for (const handler of broker.get("cart:changed")) handler("tea");

Lines 1 to 3 are the observer way. The list lives inside cart, so the cart knows its listeners.

Lines 5 to 7 are the pub/sub way. broker is a Map, a collection of named entries. The list lives in it under the name cart:changed. Code only needs that name to reach the listeners. Both ways print their label with tea.

The bus has a cost. After a publish, it is harder to find which code runs, because the listeners live somewhere else.

1function createBus() {2  const topics = new Map();3  return {4    subscribe(topic, handler) {5      const handlers = topics.get(topic) ?? new Set();6      handlers.add(handler);7      topics.set(topic, handlers);8      return () => handlers.delete(handler);9    },10    publish(topic, payload) {11      for (const handler of topics.get(topic) ?? []) {12        handler(payload);13      }14    },15  };16}17 18const bus = createBus();19bus.subscribe("cart:changed", ({ count }) => console.log(`header ${count}`));20bus.subscribe("analytics:cart", ({ sku }) => console.log(`analytics ${sku}`));21bus.publish("cart:changed", { count: 2, sku: "book" });22bus.publish("analytics:cart", { count: 2, sku: "book" });

• Line 4 is subscribe. It adds a listener to the list for one topic.
• Line 10 is publish. It calls only the listeners for that exact topic.
• Line 19 subscribes the header to cart:changed. Line 20 subscribes analytics to analytics:cart.
• Line 21 publishes on cart:changed. Only the header runs, and it prints header 2.
• Line 22 publishes on analytics:cart. Only analytics runs, and it prints analytics book.

Give topics clear names that start with the area they belong to, like cart:changed, analytics:cart, or cart:item:removed. Then you can search your code for them. Some buses let one listener subscribe to many topics with a pattern such as cart:*. Use that with care: it makes it harder to see which code runs.

An event emitter is an object that sends named events to its listeners. You don't have to build one yourself. The browser and Node each come with one.

In the browser, it is EventTarget. Every element on a page is an EventTarget. That is how clicks reach your listeners. You can also make a plain one with new EventTarget().

To send your own event, make a CustomEvent and put the data in its detail option. The custom events lesson shows more.

To remove many listeners at once, use an AbortController. Pass its signal when you add each listener. Later, one call to abort() removes all of them.

1const target = new EventTarget();2const group = new AbortController();3 4target.addEventListener("cart:changed", (event) => {5  console.log(`header ${event.detail.count}`);6}, { signal: group.signal });7 8target.addEventListener("cart:changed", (event) => {9  console.log(`analytics ${event.detail.sku}`);10}, { once: true });11 12target.dispatchEvent(new CustomEvent("cart:changed", {13  detail: { count: 1, sku: "book" },14}));15group.abort();16target.dispatchEvent(new CustomEvent("cart:changed", {17  detail: { count: 2, sku: "pen" },18}));

• Lines 4 to 6 add a header listener tied to group.signal.
• Lines 8 to 10 add an analytics listener with { once: true }. That means "remove me after I run once."
• Line 12 sends the first event. Both listeners run, so the console shows header 1 and analytics book. The analytics listener then removes itself.
• Line 15 calls group.abort(), which removes the header listener.
• So the second event, on line 16, prints nothing. No listeners are left.

dispatchEvent() calls every listener right away, before it returns. It doesn't wait.

Node's version is called EventEmitter. Its method names are different:

• on adds a listener.
• once adds a listener that runs only once.
• off removes a listener.
• emit sends an event.

Two more things to know. First, an event named error is special. If you emit it and no listener handles it, Node throws an error. Second, Node prints a warning when you add too many listeners to one event. That warning often means some code forgot to remove its listeners.

1import { EventEmitter } from "node:events";2 3const bus = new EventEmitter();4function header({ count }) {5  console.log(`header ${count}`);6}7function storage({ count }) {8  console.log(`storage ${count}`);9}10 11bus.on("cart:changed", header);12bus.once("cart:changed", ({ count }) => console.log(`analytics first ${count}`));13bus.on("cart:changed", storage);14bus.emit("cart:changed", { count: 1 });15bus.off("cart:changed", storage);16bus.emit("cart:changed", { count: 2 });17 18const errors = new EventEmitter();19errors.on("error", (error) => console.log(`handled ${error.message}`));20errors.emit("error", new Error("offline"));21 22const noisy = new EventEmitter();23noisy.setMaxListeners(1);24noisy.on("warn", () => {});25noisy.on("warn", () => {});26console.log(`listeners ${noisy.listenerCount("warn")}`);

• Line 14 emits the first event. The header, the once-only analytics listener, and storage all run.
• Line 15 removes storage, so line 16 reaches only the header.
• Line 20 emits error. The listener on line 19 handles it, so nothing throws.
• Line 23 sets the limit to one listener, and lines 24 and 25 add two. So Node prints a warning, and line 26 prints listeners 2.

A signal holds one current value. You call it to read the value, like price(). You change it with .set(). The clever part: a signal remembers which code read it. When the value changes, only that code runs again.

Two more words come with signals:

• A computed value is worked out from other signals. For example, total is price() times quantity().
• An effect is code that runs again whenever a signal it read changes. For example, code that prints the total.

So when quantity changes, only total and the code that prints it run again. Nothing else in the app does.

The tiny version below is real, working JavaScript. Here is how it knows who read a signal:

• Before an effect runs, it puts itself on top of a list called effectStack.
• Any signal that is read while the effect runs looks at the top of that list. It adds that effect to its own subscribers.
• When the effect finishes, it takes itself off the list.

The code also does two tidy-up jobs. It clears an effect's old subscriptions before the effect runs again. And it copies a signal's subscriber list before calling it. Real signal libraries add more, such as grouping many updates into one, but the main idea is all here.

1const effectStack = [];2 3function cleanup(runner) {4  for (const dependency of runner.dependencies) {5    dependency.delete(runner);6  }7  runner.dependencies.clear();8}9 10function effect(work) {11  const runner = () => {12    cleanup(runner);13    effectStack.push(runner);14    try {15      work();16    } finally {17      effectStack.pop();18    }19  };20  runner.dependencies = new Set();21  runner();22  return () => cleanup(runner);23}24 25function signal(value) {26  const subscribers = new Set();27  const read = () => {28    const runner = effectStack[effectStack.length - 1];29    if (runner) {30      subscribers.add(runner);31      runner.dependencies.add(subscribers);32    }33    return value;34  };35  read.set = (next) => {36    if (Object.is(next, value)) return;37    value = next;38    for (const runner of [...subscribers]) runner();39  };40  return read;41}42 43function computed(work) {44  const output = signal();45  effect(() => output.set(work()));46  return output;47}48 49const price = signal(10);Run50const quantity = signal(2);51const total = computed(() => price() * quantity());52effect(() => console.log(`total ${total()}`));53quantity.set(3);

You'll find signals in Solid, Preact Signals, and Angular. Vue's ref works in a similar way. There is a proposal to add signals to JavaScript itself, but it is only at Stage 1, an early step. So today, each framework gives you its own signals.

An observable is a stream: a source that sends values one after another, over time. Clicks, messages from a server, timer ticks, and a file arriving in pieces are all streams.

A listener gets each value through a function called next. It keeps getting values until it unsubscribes or the stream ends. RxJS is the most common library for observables.

The functors & monads lesson built a tiny observable. This lesson won't build one again. A later project lesson builds a full event emitter from scratch. Here, just learn the difference:

• A signal answers "what is the value now?"
• An observable answers "what values will arrive over time?"

1console.log(typeof EventTarget.prototype.when);

Browsers are adding observables too, through a proposal called the Observable API. In Chrome, every EventTarget already has a when() method that gives you an observable of its events. Other browsers may not have it yet. So check first, as the code above does. Checking whether a browser has a feature before you use it is called feature detection.

If you need observables in every browser today, use RxJS or your framework's tools.

Pick the smallest tool that fits. Start by asking who should own the list of listeners:

• If one object owns the data, use observer.
• If separate parts of the app should talk without importing each other, use pub/sub. The cost is that the flow is harder to follow.
• If you are in the browser or in Node, use the event emitter that comes with it.
• If you need values worked out from other values, use signals.

Read each row of the table as: "in this situation, this tool fits, for this reason."

A listener can also keep other things in memory. Say a listener uses a profile name or a page element. While the listener is in the list, that name or element stays in memory too, even after the profile is closed. So remove listeners when you are done with them.

The small example below counts listeners. It doesn't measure memory.

1const listeners = new Set();2function mountProfile(name) {3  const listener = () => console.log(name);4  listeners.add(listener);5  return () => listeners.delete(listener);6}7const closeProfile = mountProfile("Asha");8console.log(listeners.size);9closeProfile();10console.log(listeners.size);

• Line 3 makes a listener that uses name.
• Line 4 adds it to the set, so line 8 prints 1.
• Line 9 calls closeProfile(). That is the function mountProfile returned, and it removes the listener. So line 10 prints 0.

In a real page, call this cleanup function when the profile is taken off the page. JavaScript then frees the memory later, at a time it chooses. You can't make it free memory right now.

1const subscribers = new Set();2const store = {3  count: 0,4  subscribe(widget) {5    subscribers.add(widget);6    return () => subscribers.delete(widget);7  },8  publish(nextCount) {9    this.count = nextCount;10    for (const widget of [...subscribers]) {11      widget(this.count);12    }13  },14};

Common misconceptions

• "Every callback is an observer." A callback is just a function you pass to other code. The observer pattern adds a subject that keeps a list of callbacks and calls them each time something changes.
• "Observer and pub/sub are the same." They are close. But pub/sub adds a bus and topic names, so the publisher never knows who is listening.
• "Events always run later." Many don't. dispatchEvent and most simple emitters call every listener right away, before the next line runs.
• "Catching errors hides bugs." Catching an error and then ignoring it hides bugs. Catching one listener's error and reporting it keeps the other listeners working.
• "Signals and observables are the same thing." A signal answers "what is the value now?" An observable answers "what values arrive over time?"
• "A too-many-listeners warning means: raise the limit." Usually it means some code forgot to remove its listeners. Look for the missing cleanup first.

The next table lists four common problems. Read each row as: "this can go wrong, this is what happens, and this prevents it."

The last table compares the event tools with the value tools. Read across a row to see how each group answers the same question.

Key takeaways

• With observer, the subject keeps the list of listeners and calls them.
• With pub/sub, a bus keeps lists by topic, so the publisher never knows who is listening.
• Copy the list before calling listeners, give back an unsubscribe function, and catch each listener's errors.
• In the browser, use EventTarget. In Node, use EventEmitter.
• A signal is a value you can read now. An observable sends values over time.

Up next: more design patterns, such as decorator, adapter, and strategy. A later project builds a complete event emitter from scratch.