Comment le modèle d'état réactif de MobX diffère-t-il de Redux ?

Question

Accepted Answer

**MobX** adopte une approche fondamentalement différente de Redux : au lieu d'actions explicites et de mises à jour immutables, il utilise la **réactivité transparente** — vous mutez directement l'état observable, et MobX suit automatiquement les dépendances et met à jour tout ce qui en dépend (similaire à la réactivité de Vue ou aux Signals). ## MobX — observables mutables, suivi automatique ```js import { makeAutoObservable } from "mobx"; import { observer } from "mobx-react-lite"; class CounterStore { count = 0; constructor() { makeAutoObservable(this); } // make fields observable increment() { this.count++; } // ✅ DIRECT mutation — no actions, no immutability get double() { return this.count * 2; } // computed — auto-derived & cached } const store = new CounterStore(); // observer components auto-re-render when the observables they read change const Counter = observer(() => ( )); ``` Vous mutez l'état directement (`this.count++`), et MobX re-rend automatiquement uniquement les composants `observer` qui lisent `count`. Pas de reducers, actions, dispatch, ou immuabilité manuelle. ## La différence fondamentale de philosophie ```text Redux MobX Updates immutable (return new state) mutable (change in place) Mechanism explicit actions + reducers transparent reactive tracking Data flow strict one-way, predictable automatic dependency reactions Boilerplate more less Derived values selectors (manual) computed (automatic, cached) Mental model functional / explicit OOP / reactive / implicit ``` ## Comment MobX suit les dépendances ```text MobX wraps observables in proxies. When an observer component renders, MobX records which observables it READ. When any of those change, MobX re-runs exactly that component — fine-grained, automatic, no selectors needed. ``` C'est la même idée de suivi à la lecture/déclenchement à l'écriture derrière la réactivité de Vue et les Signals. ## Compromis ```text MobX pros: less boilerplate, automatic reactivity, easy derived values, OOP-friendly MobX cons: "magic" can be less explicit/traceable than Redux's logged actions; mutation-based flow is harder to time-travel debug than pure reducers ``` ## Pourquoi c'est important MobX représente l'école **réactive/mutable** de la gestion d'état — l'opposé de l'approche **explicite/immutable** de Redux. Comprendre le contraste clarifie un axe de conception clé : explicite-et-prévisible (Redux : tracer chaque action, mais plus de boilerplate) vs. automatique-et-concis (MobX : mutez librement, moins de code, mais moins explicite). Le même principe réactif sous-tend Vue et Signals, donc comprendre MobX illumine toute une famille d'outils d'état et vous aide à choisir entre prédictibilité et ergonomie pour un projet donné.