Что такое паттерн «издатель/подписчик» для состояния и каковы его компромиссы?

Question

Accepted Answer

**Издатель/подписчик (pub/sub)** — это паттерн обмена сообщениями, где **издатели** генерируют события, а **подписчики** на них реагируют, не зная друг о друге напрямую. Многие библиотеки управления состоянием (и системы событий) построены на его основе — хранилище *публикует* изменения, а компоненты *подписываются* на них.

## Минимальное хранилище pub/sub

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

Компоненты вызывают `subscribe(callback)` для получения уведомлений; хранилище вызывает каждого подписчика при изменении состояния (`setState`). По сути это то, как работают `store.subscribe` в Redux, Zustand и event emitters под капотом.

## Преимущество развязки

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

Эта слабая связь позволяет независимым частям приложения реагировать на одни и те же изменения без прямых ссылок друг на друга — гибко и расширяемо.

## Компромиссы

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

Самая большая практическая опасность — **забыть отписаться** (например, при размонтировании компонента), что приводит к утечкам памяти и может привести к срабатыванию обратных вызовов на мёртвых компонентах.

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

## Почему это важно

Pub/sub является **подлежащим механизмом** большинства библиотек управления состоянием и систем событий — его понимание разъясняет, как хранилища уведомляют компоненты и как работают `subscribe`/`unsubscribe`.

Оно объясняет как преимущества (развязанная, гибкая коммуникация), так и подводные камни (неявный поток данных, который сложно отследить, и утечки памяти из неочищенных подписок).

Распознание pub/sub помогает вам рассуждать о реактивности под капотом и подчёркивает важность всегда очищать подписки.