Aller au contenu principal

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 ;
  • localStorage pour certains réglages backoffice ;
  • sessionStorage pour 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

TypeExemplesStratégie cible
État UImodale ouverte, filtre, tab active, loaderLocal au composant ou à la page.
État sessionutilisateur connecté, rôle, statutSource auth + contrôles backend.
État serveuracteurs, publications, documents, statistiquesFetch/SWR/API, invalidation claire.
Préférencessidebar backoffice, session analyticsStockage 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.