Cas pratiques Zustand

Contexte : Une application stocke une liste d'éléments dans Zustand. Le Problème : Aucune action ne permet de supprimer un élément spécifique. Contraintes : Respecter l'immuabilité du state. Livrable attendu : Implémenter une fonction removeItem supprimant un élément selon son identifiant.

Contexte : Un composant React doit afficher et modifier une valeur stockée dans Zustand. Le Problème : Le composant n'utilise pas correctement le hook du store et ne se met pas à jour. Contraintes : Utiliser correctement le hook généré par create. Livrable attendu : Connecter correctement le composant au store afin qu'il lise la valeur et déclenche les actions correspondantes.

Contexte : Un store gère un objet profile contenant plusieurs propriétés. Le Problème : La mise à jour d'un champ écrase les autres propriétés. Code actuel : updateName: (name) => set({ profile: { name } }) Contraintes : Conserver les autres propriétés existantes du profile. Livrable attendu : Corriger la fonction pour fusionner correctement les propriétés sans perdre les données existantes.

Contexte : Un store Zustand gère une liste de tâches dans une application interne. Le Problème : Une mutation directe du state empêche React de déclencher correctement les re-renders. Contraintes : Respecter l'immuabilité du state lors des mises à jour. Code actuel : const useStore = create((set) => ({ todos: [], addTodo: (todo) => set((state) => { state.todos.push(todo); return state; }) })); Livrable attendu : Corriger la fonction addTodo afin de respecter l'immuabilité et garantir une mise à jour correcte du state.

Contexte : Un composant consomme l'ensemble du state alors qu'il n'utilise qu'une propriété. Le Problème : Le composant se re-render inutilement lors de modifications non pertinentes. Contraintes : Utiliser une sélection ciblée via le hook Zustand. Livrable attendu : Modifier l'utilisation du store afin de sélectionner uniquement la propriété nécessaire.

Contexte : Une application doit permettre de basculer entre mode clair et sombre. Le Problème : Le state du thème est actuellement local à chaque composant. Contraintes : Centraliser la gestion du thème via un store Zustand. Livrable attendu : Créer un store exposant isDarkMode et une fonction toggleTheme permettant de basculer l'état.

Contexte : Une application doit stocker les informations de l'utilisateur connecté. Le Problème : Les données sont stockées dans plusieurs états locaux. Contraintes : Centraliser les informations utilisateur dans un store Zustand. Livrable attendu : Créer un store exposant user et une fonction setUser pour mettre à jour les données.

Contexte : Vous développez une petite application React nécessitant un compteur partagé entre plusieurs composants. Le Problème : Le state est actuellement géré via props drilling, ce qui complexifie inutilement la structure. Contraintes : Utiliser uniquement Zustand sans middleware additionnel. Implémenter un store simple avec une valeur count et une action increment. Livrable attendu : Créer un store Zustand minimal exposant count et une fonction increment permettant de modifier l'état global proprement.

Contexte : Une interface nécessite un compteur simple contrôlé globalement. Le Problème : Seule l'incrémentation est implémentée. Contraintes : Ajouter une action decrement proprement intégrée au store. Livrable attendu : Étendre le store pour gérer l'incrémentation et la décrémentation proprement.

Contexte : Une application nécessite de pouvoir réinitialiser son état global lors de la déconnexion utilisateur. Le Problème : Aucun mécanisme de reset n'est implémenté dans le store. Contraintes : Implémenter une fonction reset ramenant le state à sa valeur initiale. Livrable attendu : Ajouter une action reset proprement intégrée au store permettant de restaurer l'état initial.

Contexte : Une application React commence à grandir et plusieurs états globaux sont regroupés dans un seul store volumineux. Le Problème : Le store devient difficile à maintenir, avec des responsabilités mélangées (auth, panier, notifications). Contraintes : Utiliser Zustand uniquement. Organiser le store par slices modulaires sans middleware externe. Livrable attendu : Refactoriser le store en slices distinctes (authSlice, cartSlice, uiSlice) combinées dans un store unique propre et scalable.

Contexte : Le store contient un objet complexe avec plusieurs niveaux imbriqués. Le Problème : Une mise à jour partielle écrase accidentellement des propriétés internes. Code actuel : updateCity: (city) => set({ user: { address: { city } } }) Contraintes : Préserver les autres propriétés de user et address. Livrable attendu : Refactoriser la mise à jour afin de fusionner correctement les objets imbriqués sans perte de données.

Contexte : Une application e-commerce doit filtrer une liste de produits selon plusieurs critères. Le Problème : Les filtres sont gérés localement dans différents composants. Contraintes : Centraliser les filtres dans un store Zustand. Livrable attendu : Concevoir un store gérant plusieurs filtres combinables et exposant une fonction permettant de mettre à jour dynamiquement les critères.

Contexte : Une application doit charger des données utilisateurs depuis une API. Le Problème : La logique asynchrone est actuellement dispersée dans les composants. Contraintes : Centraliser la logique asynchrone dans le store Zustand. Livrable attendu : Implémenter une action async dans le store gérant loading, success et error proprement.

Contexte : Une application met à jour immédiatement l'interface avant confirmation serveur. Le Problème : En cas d'erreur API, le state reste incohérent. Contraintes : Implémenter une logique d'optimistic update directement dans le store. Livrable attendu : Mettre en place un mécanisme permettant de sauvegarder l'ancien state et d'effectuer un rollback en cas d'échec.

Contexte : Une application doit conserver certaines données (ex: panier) après rechargement de la page. Le Problème : Les données disparaissent lors du refresh. Contraintes : Utiliser le middleware persist natif de Zustand. Aucun stockage externe. Livrable attendu : Mettre en place une configuration persist permettant de sauvegarder et restaurer automatiquement certaines parties du state.

Contexte : Une fonctionnalité doit déclencher une action en dehors d'un composant React lorsqu'une valeur change. Le Problème : Aucun mécanisme d'abonnement externe n'est utilisé. Contraintes : Utiliser subscribe de Zustand. Livrable attendu : Mettre en place un abonnement externe au store permettant de réagir aux changements sans passer par un composant.

Contexte : Une application doit afficher des notifications globales déclenchées depuis différents composants. Le Problème : La logique est dupliquée et non centralisée. Contraintes : Utiliser un store Zustand unique pour gérer la file de notifications. Livrable attendu : Créer un système permettant d'ajouter et supprimer des notifications via actions dédiées.

Contexte : Un composant consomme plusieurs propriétés du store et se re-render trop souvent. Le Problème : Les mises à jour non pertinentes déclenchent des re-renders inutiles. Contraintes : Utiliser une sélection précise avec shallow comparison si nécessaire. Livrable attendu : Refactoriser la consommation du store afin de limiter les re-renders aux changements réellement nécessaires.

Contexte : Une application multi-utilisateurs doit gérer des rôles et permissions globaux. Le Problème : Les permissions sont évaluées localement dans chaque composant. Contraintes : Centraliser les rôles et permissions dans Zustand. Livrable attendu : Concevoir un store structuré permettant de vérifier les permissions via fonctions dédiées et sélecteurs efficaces.

Contexte : Vous développez une application SaaS modulaire où certaines fonctionnalités ne sont chargées qu'à la demande. Le Problème : Le store Zustand central grossit et toutes les slices sont chargées dès le démarrage, ce qui nuit aux performances et à la maintenabilité. Contraintes : Utiliser uniquement Zustand natif. Permettre une injection dynamique de slices sans recréer complètement le store. Livrable attendu : Concevoir une architecture permettant de composer dynamiquement des slices Zustand par feature tout en conservant une structure claire et scalable.

Contexte : Une application multi-rôles doit contrôler finement l'accès aux fonctionnalités. Le Problème : Les vérifications de permissions sont dispersées dans les composants. Contraintes : Centraliser rôles et permissions dans Zustand avec fonctions dérivées. Livrable attendu : Mettre en place un store structuré permettant de vérifier dynamiquement les droits utilisateur via sélecteurs performants.

Contexte : Une fonctionnalité de recherche déclenche des appels API à chaque frappe clavier. Le Problème : Les réponses arrivent dans le désordre et écrasent parfois les résultats plus récents. Contraintes : Gérer la concurrence directement dans le store Zustand sans librairie externe. Livrable attendu : Implémenter un mécanisme permettant d'annuler ou d'ignorer les requêtes obsolètes afin de garantir la cohérence des résultats.

Contexte : Une application manipule des milliers d'entités (produits, utilisateurs, commandes). Le Problème : Les mises à jour deviennent coûteuses et les recherches inefficaces. Contraintes : Mettre en place une structure normalisée avec indexation par identifiant. Livrable attendu : Concevoir un state normalisé performant avec accès optimisé aux entités et mises à jour efficaces.

Contexte : Une application collaborative met à jour immédiatement l'interface avant confirmation serveur. Le Problème : En cas d'échec API, l'état local devient incohérent et difficile à restaurer. Contraintes : Mettre en place un mécanisme transactionnel interne au store. Livrable attendu : Concevoir un système permettant de sauvegarder l'état précédent, appliquer une mise à jour optimiste puis effectuer un rollback automatique en cas d'erreur.

Contexte : Une application effectue de nombreux appels API redondants pour les mêmes données. Le Problème : Les données sont rechargées inutilement, augmentant la latence et la charge réseau. Contraintes : Implémenter un système de cache dans le store Zustand avec timestamp et logique d'invalidation. Livrable attendu : Concevoir une stratégie de cache permettant de stocker les réponses API, vérifier leur validité temporelle et invalider proprement les données.

Contexte : L'équipe souhaite pouvoir revenir à un état précédent pour debug interne. Le Problème : Aucun historique d'état n'est conservé dans le store. Contraintes : Implémenter un historique interne sans librairie externe. Livrable attendu : Concevoir un système permettant d'enregistrer les états successifs et de naviguer en arrière (undo/redo).

Contexte : Une application contient de nombreux effets secondaires (API, analytics, logs). Le Problème : Les effets secondaires sont parfois déclenchés directement dans les composants, rendant l'architecture fragile. Contraintes : Centraliser toute la logique asynchrone dans le store Zustand. Livrable attendu : Proposer une architecture d'orchestration où toutes les opérations asynchrones et side effects sont gérés exclusivement dans le store.

Contexte : Une application manipule un state volumineux avec des centaines d'éléments. Le Problème : De nombreux composants se re-render inutilement à cause de sélections larges du state. Contraintes : Utiliser des sélecteurs dérivés et shallow comparison pour minimiser les re-renders. Livrable attendu : Refactoriser la consommation du store afin d'isoler précisément les dépendances et d'améliorer significativement les performances.

Contexte : Une application ouverte dans plusieurs onglets doit partager le même state global. Le Problème : Les modifications effectuées dans un onglet ne sont pas reflétées dans les autres. Contraintes : Utiliser localStorage et l'événement storage natif du navigateur. Livrable attendu : Implémenter un mécanisme synchronisant automatiquement le store Zustand entre plusieurs onglets ouverts.