O que é o padrão publish/subscribe para state e quais são seus trade-offs?

Question

Accepted Answer

**Publicar/inscrever (pub/sub)** é um padrão de mensagens onde **editores** emitem eventos e **assinantes** reagem a eles, sem se conhecerem diretamente. Muitas bibliotecas de state (e sistemas de eventos) são construídas sobre ele — uma store *publica* mudanças e componentes *se inscrevem* nelas.

## Uma store pub/sub mínima

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

Componentes chamam `subscribe(callback)` para serem notificados; a store chama cada assinante quando o state muda (`setState`). Isso é essencialmente como `store.subscribe` do Redux, Zustand e event emitters funcionam por baixo.

## O benefício do desacoplamento

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

Este acoplamento frouxo permite que partes não relacionadas de um app reajam às mesmas mudanças sem referências diretas umas às outras — flexível e extensível.

## Por que isso importa

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

O maior perigo prático é **esquecer de desinscrever** (por exemplo, ao desmontar componente), o que vaza memória e pode fazer com que callbacks disparem em componentes mortos.

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

## Por que isso importa

Pub/sub é o **mecanismo subjacente** da maioria das bibliotecas de state e sistemas de eventos — entendê-lo desmistifica como as stores notificam componentes e como `subscribe`/`unsubscribe` funcionam.

Explica tanto o poder (comunicação desacoplada e flexível) quanto as pegadinhas (fluxo de dados implícito difícil de rastrear, e vazamentos de memória de inscrições não limpas).

Reconhecer pub/sub ajuda você a raciocinar sobre reatividade por baixo dos panos e reforça a importância de sempre limpar inscrições.