State management
Statut
Document de cadrage frontend — version initiale.
État actuel visible
Le state management visible repose principalement sur React :
useState;useEffect;useMemo;useRef;useCallback;- état local par page ou composant ;
localStoragepour certains réglages backoffice ;sessionStoragepour le suivi analytics de session ;- SWR ponctuel dans le gestionnaire de documents.
Aucune dépendance Redux, Zustand ou autre store global n'est visible dans les package.json inspectés.
Principes
- Garder l'état local tant qu'il n'a pas besoin d'être partagé.
- Éviter un store global par défaut.
- Distinguer état UI, état serveur et état de session.
- Ne pas dupliquer les données serveur inutilement.
- Garder les caches compréhensibles.
- Limiter les effets de bord dans les composants.
Types d'état
| Type | Exemples | Stratégie cible |
|---|---|---|
| État UI | modale ouverte, filtre, tab active, loader | Local au composant ou à la page. |
| État session | utilisateur connecté, rôle, statut | Source auth + contrôles backend. |
| État serveur | acteurs, publications, documents, statistiques | Fetch/SWR/API, invalidation claire. |
| Préférences | sidebar backoffice, session analytics | Stockage local limité et explicite. |
Backoffice
Le backoffice utilise des états locaux nombreux par page. C'est acceptable pour un outil d'administration, mais les pages complexes doivent éviter de concentrer trop de logique métier dans le composant.
La cible est de déplacer progressivement :
- accès données ;
- transformations répétées ;
- validations métier ;
- règles d'autorisation ;
vers des services, hooks ou l'API backend selon le cas.
Site public
Le site public doit limiter l'état global pour rester rapide et lisible.
Les interactions comme favoris, modales, recherche, filtres et carte peuvent rester locales ou liées à l'URL si cela améliore le partage et le retour navigateur.
Vision cible
Un store global ne doit être introduit que si un besoin réel apparaît :
- session multi-composants difficile à gérer ;
- panier ou achat in-app futur ;
- workflow multi-étapes partagé ;
- synchronisation forte entre zones d'écran.
Sans besoin confirmé, React + hooks + cache données ciblé suffit.
Points à clarifier
- Standard de cache côté frontend après migration vers API Laravel.
- Usage cible de SWR sur plus de pages.
- Convention d'état URL pour filtres et recherche.
- Gestion centralisée éventuelle des notifications frontend.