What is the publish/subscribe pattern for state, and its trade-offs?

Question

Accepted Answer

**Publish/subscribe (pub/sub)** is a messaging pattern where **publishers** emit events and **subscribers** react to them, without knowing about each other directly. Many state libraries (and event systems) are built on it — a store *publishes* changes and components *subscribe* to them.

## A minimal pub/sub store

```js
function createStore(initial) {
  let state = initial;
  const subscribers = new Set();

return {
    getState: () => state,
    setState(next) {
      state = { ...state, ...next };
      subscribers.forEach((fn) => fn(state)); // PUBLISH: notify all subscribers
    },
    subscribe(fn) {
      subscribers.add(fn);                     // SUBSCRIBE
      return () => subscribers.delete(fn);      // return an unsubscribe function
    },
  };
}
```

Components call `subscribe(callback)` to be notified; the store calls every subscriber when state changes (`setState`). This is essentially how Redux's `store.subscribe`, Zustand, and event emitters work under the hood.

## The decoupling benefit

```text
Publisher (the store) doesn't know WHO is listening.
Subscribers don't know WHO published.
→ They're decoupled, communicating only through the event/store.
```

This loose coupling lets unrelated parts of an app react to the same changes without direct references to each other — flexible and extensible.

## The trade-offs

```text
✓ Pros: decoupled, flexible, many-to-many communication, easy to add listeners
✗ Cons:
  - Implicit flow — hard to trace WHO reacts to an event (vs explicit calls)
  - Memory leaks — forgetting to UNSUBSCRIBE keeps dead listeners alive
  - Debugging — indirection makes "why did this run?" harder to answer
  - Ordering — subscriber execution order can be non-obvious
```

The biggest practical danger is **forgetting to unsubscribe** (e.g. on component unmount), which leaks memory and can cause callbacks to fire on dead components.

```jsx
useEffect(() => {
  const unsub = store.subscribe(handleChange);
  return unsub; // ✅ cleanup — unsubscribe on unmount
}, []);
```

## Why it matters

Pub/sub is the **underlying mechanism** of most state libraries and event systems — understanding it demystifies how stores notify components and how `subscribe`/`unsubscribe` work.

It explains both the power (decoupled, flexible communication) and the pitfalls (implicit data flow that's hard to trace, and memory leaks from un-cleaned subscriptions).

Recognizing pub/sub helps you reason about reactivity under the hood and reinforces the importance of always cleaning up subscriptions.