Observer & pub/sub

React without tight coupling

Modern JavaScript apps are full of reactions: a cart changes, the header badge updates, analytics records the item, storage persists the cart, and a recommendation widget wakes up. The risky version is one function importing every reaction directly.

Observer-style patterns separate the thing that changed from the things that react. You still need discipline: clear topics, returned cleanup functions, copied subscriber lists, and error isolation keep the pattern production-ready.

This lesson builds on callbacks, closures, events, and custom events. It also links to functors & monads for the tiny Observable you have already seen, and to memory management for cleanup leaks.

The code below is easy to write and hard to maintain. updateCart owns cart data, header rendering, analytics, and storage. Adding a fourth reaction means editing this function again. Testing the cart now requires header, analytics, and storage details.

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");

Read it line by line: line 4 changes the cart, line 5 calls header UI, line 6 calls analytics, and line 7 calls persistence. Those are three separate reasons for this function to change. Observer-style code keeps the cart update small and lets reactions subscribe from their own modules.

In the observer pattern, a subject exposes subscribe. Each subscriber is a callback. subscribe returns an unsubscribe function, so cleanup is local and explicit. When the subject changes, it notifies observers in the order they subscribed.

The subject below uses two production safeguards. First, it copies observers with [...observers] before notifying. Second, it catches one observer's error so later observers still run. Step through the example and watch storage unsubscribe itself during the first notification.

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()}`);

Notice the exact order: header runs, analytics throws and is isolated, storage still runs, then storage removes itself. The second notification reaches only header and analytics. That behavior depends on the copied list and per-observer try/catch.

Pub/sub goes one step further than observer. A publisher does not hold the subscriber list. A broker, sometimes called an event bus, owns topic names and handler sets. The publisher emits a topic and payload; subscribers elsewhere choose which topics they want.

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 subscribes a handler to a topic. Line 10 publishes only to handlers for that exact topic. Naming topics with namespaces such as cart:changed, analytics:cart, or cart:item:removed makes events searchable. Some brokers add wildcards such as cart:*; use them carefully because broad listeners can hide control flow.

JavaScript platforms already ship event systems. In the browser, EventTarget powers DOM events. You can dispatch your own CustomEvent with a detail payload, just like the custom events lesson shows. Use AbortController when several listeners should be removed together.

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}));

The first dispatch logs the header and analytics lines. The analytics listener is once, so it removes itself. Then group.abort() removes the header listener. The second dispatch does not log anything because every listener is gone.

Node's EventEmitter uses different method names: on, once, off, and emit. The error event is special: emitting it with no error listener throws. Node also warns when too many listeners are added to the same event, often pointing at forgotten cleanup.

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")}`);

Signals are not just event lists. A signal is a current value. A computed signal derives a current value from other signals. An effect runs when the signals it read last time change. That is why signal systems feel precise: updating quantity should re-run the total computation, not every subscriber in the app.

The tiny runtime below is real JavaScript. It uses a current-effect stack for automatic dependency tracking, cleans old dependencies before re-running an effect, and copies subscribers before notifying them. Production libraries add batching, scheduling, devtools, and edge-case handling, but the core idea is 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 will see this model in Solid, Preact Signals, Angular signals, and Vue refs. The TC39 Signals proposal is currently Stage 1, so the standard JavaScript language does not have built-in signals yet; frameworks provide their own APIs today.

Observables model future values arriving over time: clicks, WebSocket messages, timer ticks, chunks from a stream, or repeated async results. A subscriber receives next values until it unsubscribes or the stream completes. RxJS is the common production library for composing these streams.

The functors & monads lesson built a tiny Observable to explain mapping over a pushed value. This lesson does not rebuild a full observable library; the later event-emitter project will build a full emitter from scratch. Here, focus on the choice: observables are values over time; signals expose a current value now.

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

The WICG Observable API brings native observable-style event streams to the web. Current Chrome exposes EventTarget.prototype.when; feature-detect it because browser support and API shape can evolve. If you need portable stream operators today, use RxJS or a framework-provided abstraction.

The best pattern is the smallest one that explains ownership. If one subject owns the state, observer is clear. If unrelated modules communicate by named topics, pub/sub may be worth the traceability cost. If you are in a browser or Node API, prefer the platform emitter. If the problem is derived UI state, signals are usually a better fit than a broad event bus.

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. Observer adds a subject that stores callbacks and notifies them over time.
• “Observer and pub/sub are the same.” They are related, but pub/sub adds a broker and topic names so publishers do not know subscribers at all.
• “Events are always asynchronous.” Many JavaScript notifications, including dispatchEvent and most simple emitters, run synchronously.
• “Catching errors hides bugs.” Swallowing errors hides bugs. Isolating one observer and reporting the error keeps unrelated reactions alive.
• “Signals and observables are interchangeable.” Signals answer “what is the value now?” Observables answer “what values arrive over time?”
• “Max listeners warnings mean raise the limit.” They often mean you forgot to unsubscribe, so investigate cleanup first.

Key takeaways

• Observer keeps a subject and its observer list together.
• Pub/sub adds a broker and topics so publishers do not know subscribers.
• Copy subscriber lists before notifying, return unsubscribe functions, and isolate errors.
• Use browser EventTarget and Node EventEmitter when the platform already provides the event system.
• Signals model current values; observables model pushed values over time.

Up next: structural and behavioral patterns, then a later project that builds a complete event emitter from scratch.