Was ist das Publish/Subscribe-Muster für State und welche Trade-offs gibt es?

Question

Accepted Answer

**Publish/Subscribe (Pub/Sub)** ist ein Messaging-Pattern, bei dem **Publisher** Events emittieren und **Subscriber** darauf reagieren, ohne sich direkt zu kennen. Viele State-Libraries (und Event-Systeme) basieren darauf — ein Store *published* Änderungen und Komponenten *subscriben* sich dafür.

## Ein minimales 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
    },
  };
}
```

Komponenten rufen `subscribe(callback)` auf, um benachrichtigt zu werden; der Store ruft jeden Subscriber auf, wenn sich der State ändert (`setState`). Dies ist im Grunde, wie Redux's `store.subscribe`, Zustand und Event Emitter unter der Haube funktionieren.

## Der Entkopplungs-Vorteil

```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.
```

Diese lose Kopplung ermöglicht es nicht miteinander verknüpften Teilen einer Anwendung, auf die gleichen Änderungen zu reagieren, ohne direkte Referenzen zu haben — flexibel und erweiterbar.

## Die 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
```

Die größte praktische Gefahr ist, das **Unsubscribe zu vergessen** (z. B. beim Unmount einer Komponente), was zu Memory Leaks führt und dazu, dass Callbacks auf tote Komponenten feuern können.

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

## Warum es wichtig ist

Pub/Sub ist der **zugrundeliegende Mechanismus** der meisten State-Libraries und Event-Systeme — sein Verständnis erklärt, wie Stores Komponenten benachrichtigen und wie `subscribe`/`unsubscribe` funktionieren.

Es erklärt sowohl die Stärken (entkoppelte, flexible Kommunikation) als auch die Fallstricke (impliziter Datenfluss, der schwer zu verfolgen ist, und Memory Leaks durch nicht bereinigten Subscriptions).

Pub/Sub zu erkennen hilft dir, über Reaktivität unter der Haube nachzudenken, und unterstreicht die Wichtigkeit, Subscriptions immer zu bereinigen.