62 lines
3.3 KiB
Markdown
62 lines
3.3 KiB
Markdown
# ADR 003 — Pas de Zustand pour la V2
|
|
|
|
**Statut :** Accepté
|
|
**Date :** 2026-04-17
|
|
**Décideur :** Hermann
|
|
|
|
---
|
|
|
|
## Contexte
|
|
|
|
Question posée : faut-il introduire un store global (Zustand, Jotai, Redux Toolkit) dès le scaffold du frontend, en prévision de la complexité future du produit ?
|
|
|
|
Arguments en faveur d'une intégration précoce :
|
|
- La T2 Live a une state machine complexe (idle → connecting → listening → speaking → processing → ended/error).
|
|
- Plusieurs composants pourraient devoir lire le plan utilisateur actuel.
|
|
- Un produit "scalable" justifierait une gestion d'état "moderne".
|
|
|
|
## Options envisagées
|
|
|
|
### Option A — Zustand dès le départ
|
|
|
|
- Avantages : prêt le jour où on en aura besoin, un seul endroit pour l'état global.
|
|
- Inconvénients : dépendance supplémentaire à maintenir, code plus abstrait pour des cas qui ne la nécessitent pas, risque que les devs "poussent" de l'état dans le store par réflexe même quand `useState` suffit.
|
|
|
|
### Option B — Pas de store global, stratégie en trois couches
|
|
|
|
- **État serveur** → TanStack Query (cache, refetch, invalidation après webhook Stripe).
|
|
- **État T2 Live** → `useReducer` local avec une state machine explicite, dans `features/t2-live/hooks/useT2LiveSession.ts`.
|
|
- **État UI local** → `useState` / `useContext` pour les cas simples (ex : ouverture d'une modal).
|
|
|
|
- Avantages : zéro dépendance supplémentaire, chaque composant gère son propre état, TanStack Query couvre 90% des besoins (tout ce qui vient du serveur).
|
|
- Inconvénients : si plusieurs composants non-parents ont besoin de partager un état client complexe (non-serveur), il faudra passer par React Context ou migrer vers Zustand à ce moment-là.
|
|
|
|
## Décision
|
|
|
|
**Option B** — pas de store global pour la V2.
|
|
|
|
Règle d'introduction future : Zustand (ou équivalent) ne sera introduit que si un cas concret apparaît où plusieurs composants non-parents partagent un état client complexe qui ne peut pas être géré par TanStack Query ni par un Context React local. Jusque là, on s'en passe.
|
|
|
|
## Conséquences
|
|
|
|
**Positives :**
|
|
- Une dépendance en moins dans `package.json`.
|
|
- Un nouveau dev ne se demande pas "pourquoi Zustand pour un produit aussi simple ?".
|
|
- Évite le piège classique : dès qu'un store global existe, les devs y poussent tout, y compris ce qui devrait rester local. Le résultat est un store-spaghetti.
|
|
- TanStack Query gère déjà la synchronisation serveur → UI, ce qui couvre le plan utilisateur, les productions, les rapports, l'historique.
|
|
|
|
**Négatives :**
|
|
- Si un besoin complexe de partage d'état client apparaît tôt, il faudra migrer. Mitigation : TanStack Query + Context suffisent dans 95% des cas prévisibles.
|
|
|
|
**À revisiter si :**
|
|
- Un composant du header doit réagir en temps réel à un événement du composant de simulation (sans passer par le serveur).
|
|
- La state machine T2 Live devient partagée entre plusieurs écrans (peu probable).
|
|
- L'application a plus de 10 écrans avec de l'état client partagé complexe.
|
|
|
|
Dans ces cas, introduire Zustand sera une session dédiée avec migration progressive — pas une réécriture.
|
|
|
|
## Références
|
|
|
|
- ADR 002 (API client découplé)
|
|
- TanStack Query docs — stratégie de cache
|
|
- `ARCHITECTURE.md` §4 (structure `features/` + `shared/`)
|