~2 min de lecture
🎯 Faut-il un store Angular dans votre projet ? Voici ma grille de décision
Dans un projet Angular, la tentation d’ajouter un store (NgRx, Signal Store, Akita…) peut venir très vite.
Mais as-tu vraiment besoin d’un store ? Voici les seules questions que je me pose avant de faire ce choix.
🧪 1. Est-ce uniquement de la lecture de données ?
✅ Oui → Alors pas besoin de store.
- 📍 Si lecture à un seul endroit : un simple service avec appel HTTP suffit.
- 📍 Si lecture à plusieurs endroits : un service avec
shareReplayde RxJS est la solution la plus simple et efficace.
class HttpDataGateway {
readonly data$ = this.http.get<Data[]>('/api/data').pipe(shareReplay(1));
}
🔁 2. Est-ce un flux lecture/écriture mais utilisé dans un unique composant ?
✅ Oui → Pas besoin de store non plus.
➡️ Un service local ou injectable avec BehaviorSubject ou un Signal fera très bien le job.
🔄 3. Est-ce un flux lecture/écriture partagé entre plusieurs endroits de l’application ?
✅ Oui → C’est ici que le store devient pertinent.
- Tu veux centraliser l’état.
- Tu veux éviter le spaghetti de services et d’
input/output. - Tu veux une architecture testable et scalable.
🎯 Alors un store (NgRx, Signal Store…) est une excellente solution.
🧠 Synthèse en une grille
| Cas de figure | Besoin d’un store ? | Solution recommandée |
|---|---|---|
| Lecture simple dans un composant | ❌ Non | Service avec appel HTTP |
| Lecture à plusieurs endroits | ❌ Non | Service + shareReplay |
| Lecture/écriture dans un seul composant | ❌ Non | Service + BehaviorSubject/Signal |
| Lecture/écriture partagée entre plusieurs modules | ✅ Oui | Store (NgRx, Signal Store, etc.) |
🧘 Règle d’or : Commence simple
Un bon projet Angular commence sans store.
Un excellent projet Angular ajoute un store quand il en a besoin.
📚 Envie de creuser Angular ?
👉🏼 ➡️ Découvre EasyAngularKit