État du champ d’application par durée de vie : quand un React Portal a réellement besoin d’un stockage global

Les équipes qui développent des portails internes commencent souvent la discussion sur l’état par « Redux ou Zustand ? ». Une première question plus utile est de déterminer quels éléments d’état ont réellement besoin d’être globaux. Cet article montre comment classer l’état des portails en fonction de celui qui en est responsable et de la durée pendant laquelle il doit persister, pourquoi placer un état à courte durée de vie dans un stockage global génère constamment des bugs de nettoyage, et quand il est opportun d’utiliser une bibliothèque globale.

La plupart des états de portail sont à courte durée de vie

Les portails sont généralement des ensembles de workflows distincts. Un utilisateur ouvre une page, effectue une recherche ou modifie quelque chose, termine la tâche et se rend dans une autre partie de l’application. Les valeurs des formulaires, les filtres, les lignes de tableau sélectionnées, l’onglet actif ainsi que le fait qu’un modal soit ouvert appartiennent tous à cette page ou à ce workflow. Ils ont rarement besoin de persister sur plusieurs routes non liées entre elles.

Seul un petit ensemble de données est véritablement applicable à l’ensemble de l’application :

• l’utilisateur connecté ;
• l’état d’authentification et les permissions ;
• l’organisation ou le locataire actuel ;
• les préférences de thème et de langue.

Presque tout le reste devrait rester lié à la fonctionnalité qui en est responsable.

Les stores globaux transforment la durée de vie en tâche de nettoyage

Lorsque l’on stocke des états temporaires dans Redux, Zustand, MobX ou tout autre store global, ces derniers survivent à l’écran qui les a créés. Il devient alors nécessaire d’ajouter du code supplémentaire pour les réinitialiser lors de la navigation, après soumission, à la sortie de connexion, en cas de changement de locataire et à chaque autre point de sortie. En omettant l’un de ces points, un utilisateur peut se retrouver sur une page affichant des filtres obsolètes, des sélections anciennes ou des valeurs de formulaire partiellement remplies provenant d’une visite précédente. Ces bugs sont difficiles à reproduire car ils dépendent de la séquence exacte des écrans visités par l’utilisateur.

La règle de base est simple : si l’état global doit constamment être effacé pour se comporter comme un état local, il aurait probablement dû être local dès le début.

Choisissez la portée la plus restreinte possible

Associez chaque élément d’état à l’outil le plus ciblé qui couvre toute sa durée de vie :

• l’état du composant pour le comportement de l’interface concernant un seul composant ;
• React Context pour les états partagés au sein d’une fonctionnalité ou d’un groupe de routes liées ;
• les paramètres de recherche URL pour les filtres, la pagination et autres états de navigation, ce qui permet également aux vues d’être partagées et de survivre à un rechargement ;
• une bibliothèque d’état serveur comme TanStack Query pour les données récupérées depuis le backend, puisque le cacheage et l’invalidation en font sa fonction plutôt que celle de votre stockage ;
• un stockage global uniquement pour les états clients qui concernent réellement l’ensemble de l’application.

Le contexte au niveau des routes mérite une mention spéciale. Lorsque vous placez un fournisseur autour d’un groupe de routes, le fait de ne pas monter ce groupe démonte automatiquement le fournisseur et son état disparaît. Le cycle de vie des composants de React s’occupe du nettoyage que vous auriez sinon dû effectuer manuellement. Si ce qui vous pousse à utiliser un store est vraiment le besoin de transmettre des props à travers de nombreuses couches, il s’agit d’un problème distinct pour lequel il existe des solutions plus simples, abordées dans pourquoi le passage des props à travers plusieurs niveaux n’est pas une raison d’installer Redux ou Zustand.

Lorsqu’un store global trouve sa place

Redux, Zustand et des bibliothèques similaires sont le choix idéal lorsque l’état doit intentionnellement persister sur des écrans non liés entre eux. Les cas typiques incluent :

• les paniers d’achat ;
• les flux de paiement complexes qui s’étendent sur plusieurs pages ;
• les brouillons qui doivent être conservés ;

• Applications optimisées pour le mode hors ligne ;
• Systèmes de messagerie ou de notifications applicatives ;
• Fonctionnalités d’annulation et de réexécution ;
• Fonctionnalités en temps réel nécessitant une coordination de l’état du client ;
• Flux de travail complexes avec de nombreuses transitions d’état interdépendantes.

Dans de telles situations, un état centralisé résout un véritable problème plutôt que d’en créer un.

Points clés

• Décidez du responsable et de la durée de vie avant de choisir une bibliothèque.
• L’état appartenant à un flux de travail unique doit disparaître avec ce dernier, de préférence par désinstallation plutôt que par réinitialisation manuelle.
• Gardez les données serveur dans une bibliothèque de requêtes et l’état de navigation dans l’URL.
• Réservez un stockage global pour l’état que toute l’application partage intentionnellement dans le temps ; savoir quand ne pas en utiliser fait partie d’une bonne architecture.