Qual è il pattern publish/subscribe per lo stato e quali sono i suoi compromessi?

Question

Accepted Answer

**Publish/subscribe (pub/sub)** è un pattern di messaggistica in cui i **publisher** emettono eventi e gli **subscriber** reagiscono ad essi, senza conoscersi direttamente. Molte librerie di stato (e sistemi di eventi) si basano su di esso — uno store *pubblica* i cambiamenti e i componenti *si iscrivono* ad essi.

## Un store pub/sub minimalista

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

I componenti chiamano `subscribe(callback)` per essere notificati; lo store chiama ogni subscriber quando lo stato cambia (`setState`). Questo è essenzialmente il modo in cui `store.subscribe` di Redux, Zustand e gli event emitter funzionano sotto il cofano.

## Il vantaggio del disaccoppiamento

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

Questo accoppiamento lasco consente a parti non correlate dell'app di reagire agli stessi cambiamenti senza riferimenti diretti l'una all'altra — flessibile ed estensibile.

## I compromessi

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

Il pericolo pratico più grande è **dimenticare di annullare l'iscrizione** (ad es. all'unmount del componente), il che causa perdite di memoria e può far eseguire i callback su componenti non più attivi.

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

## Perché è importante

Pub/sub è il **meccanismo sottostante** della maggior parte delle librerie di stato e dei sistemi di eventi — comprenderlo demistifica il modo in cui gli store notificano i componenti e come funzionano `subscribe`/`unsubscribe`.

Spiega sia la potenza (comunicazione disaccoppiata e flessibile) che i rischi (flusso di dati implicito difficile da tracciare e perdite di memoria da sottoscrizioni non ripulite).

Riconoscere pub/sub ti aiuta a ragionare sulla reattività dietro le quinte e rafforza l'importanza di ripulire sempre le sottoscrizioni.