Publish/subscribe (pub/sub) はメッセージングパターンで、publishers がイベントを発行し、subscribers が互いに直接知ることなくそれに反応します。多くの状態ライブラリ（およびイベントシステム）がこれに基づいています — ストアが変更を発行し、コンポーネントがそれに購読します。
() {
state = initial;
subscribers = ();
{
: state,
() {
state = { ...state, ...next };
subscribers.( (state));
},
() {
subscribers.(fn);
subscribers.(fn);
},
};
}
コンポーネントは subscribe(callback) を呼び出して通知されます。ストアは状態が変わる（setState）たびにすべてのsubscriberを呼び出します。これは本質的に Redux の store.subscribe、Zustand、およびイベントエミッターの内部動作です。
Publisher (the store) doesn't know WHO is listening.
Subscribers don't know WHO published.
→ They're decoupled, communicating only through the event/store.
この疎い結合により、アプリの無関係な部分が直接参照なしに同じ変更に反応できます — 柔軟で拡張可能です。
✓ 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
最大の実際の危険は、購読解除を忘れること（例：コンポーネントのアンマウント時）で、メモリリークが発生し、デッドコンポーネント上でコールバックが実行される可能性があります。
useEffect(() => {
const unsub = store.subscribe(handleChange);
return unsub; // ✅ cleanup — unsubscribe on unmount
}, []);
Pub/sub は、ほとんどの状態ライブラリとイベントシステムの基礎的なメカニズムです — これを理解することで、ストアがコンポーネントに通知する方法と subscribe/unsubscribe がどのように動作するかが明確になります。
パワー（疎結合で柔軟な通信）と落とし穴（トレースが難しい暗黙的なデータフローと、クリーンアップされていない購読からのメモリリーク）の両方を説明します。
pub/sub を認識することで、フードの下の反応性について推論し、常にサブスクリプションをクリーンアップすることの重要性を強調するのに役立ちます。