Publish/subscribe (pub/sub) est un pattern de messagerie où les éditeurs émettent des événements et les abonnés y réagissent, sans se connaître directement. De nombreuses bibliothèques d'état (et systèmes d'événements) en sont basées — un store publie les changements et les composants s'y abonnent.
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
},
};
}
Les composants appellent subscribe(callback) pour être notifiés ; le store appelle chaque abonné quand l'état change (setState). C'est essentiellement comment fonctionnent store.subscribe de Redux, Zustand, et les émetteurs d'événements sous le capot.
Publisher (the store) doesn't know WHO is listening.
Subscribers don't know WHO published.
→ They're decoupled, communicating only through the event/store.
Cet couplage faible permet à des parties non liées d'une application de réagir aux mêmes changements sans références directes entre elles — flexible et extensible.
✓ 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
Le plus grand danger pratique est d'oublier de se désabonner (par exemple au démontage du composant), ce qui provoque des fuites mémoire et peut faire déclencher des callbacks sur des composants morts.
useEffect(() => {
const unsub = store.subscribe(handleChange);
return unsub; // ✅ cleanup — unsubscribe on unmount
}, []);
Pub/sub est le mécanisme sous-jacent de la plupart des bibliothèques d'état et systèmes d'événements — le comprendre démystifie comment les stores notifient les composants et comment subscribe/unsubscribe fonctionnent.
Cela explique à la fois la puissance (communication découplée, flexible) et les pièges (flux de données implicite difficile à tracer, et fuites mémoire dues aux abonnements non nettoyés).
Reconnaître pub/sub vous aide à raisonner sur la réactivité sous le capot et renforce l'importance de toujours nettoyer les abonnements.