Wat is het publish/subscribe pattern voor state, en wat zijn de voor- en nadelen?

Question

Accepted Answer

**Publish/subscribe (pub/sub)** is een berichtpatroon waarbij **uitgevers** events verzenden en **abonnees** erop reageren, zonder elkaar direct te kennen. Veel state libraries (en event-systemen) zijn erop gebouwd — een store *publiceert* wijzigingen en componenten *abonneren* zich erop.

## Waarom het belangrijk is

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

Componenten roepen `subscribe(callback)` aan om op de hoogte te worden gesteld; de store roept elke abonnee aan wanneer de state verandert (`setState`). Dit is in wezen hoe Redux's `store.subscribe`, Zustand, en event emitters onder de motorkap werken.

## Het voordeel van decoupling

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

Deze losse koppeling stelt niet-gerelateerde delen van een app in staat om op dezelfde wijzigingen te reageren zonder directe verwijzingen naar elkaar — flexibel en uitbreidbaar.

## De voor- en nadelen

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

Het grootste praktische gevaar is **vergeten af te melden** (bijvoorbeeld bij component unmount), wat geheugenlekkage en callbacks op dode componenten kan veroorzaken.

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

## Waarom het belangrijk is

Pub/sub is het **onderliggende mechanisme** van de meeste state libraries en event-systemen — dit begrijpen onthult hoe stores componenten informeren en hoe `subscribe`/`unsubscribe` werken.

Het verklaart zowel de kracht (ontkoppelde, flexibele communicatie) als de valkuilen (impliciete gegevensstroom die moeilijk is na te gaan, en geheugenlekkage door niet-schoongeharkte abonnementen).

Het herkennen van pub/sub helpt je reactivity onder de motorkap te begrijpen en benadrukt het belang van het altijd opruimen van abonnementen.