حالات تطبيقية في Redux

Contexte : Un composant React doit afficher la valeur d'un compteur stocké dans Redux. Le Problème : Le composant n'est pas correctement connecté au store. Contraintes : Utiliser react-redux avec Provider et useSelector. Livrable attendu : Connecter correctement le composant afin qu'il lise la valeur du store et se mette à jour automatiquement.

Contexte : L'application possède plusieurs reducers (user, cart). Le Problème : Le state global ne correspond pas à la structure attendue. Contraintes : Utiliser combineReducers correctement. Code actuel : const rootReducer = combineReducers({ userReducer, cartReducer }); Livrable attendu : Corriger la configuration afin d'obtenir une structure d'état claire (user, cart).

Contexte : Un composant tente de déclencher une action Redux lors d'un clic. Le Problème : L'action n'est pas dispatchée correctement. Code actuel : const handleClick = () => { increment(); }; Livrable attendu : Corriger l'utilisation de useDispatch afin de déclencher correctement l'action.

Contexte : Vous reprenez une petite application React utilisant Redux pour gérer un compteur global. Le Problème : Après dispatch d'une action, l'interface ne se met pas à jour correctement car le reducer modifie directement l'état existant. Contraintes : Utiliser Redux natif sans librairie externe supplémentaire. Respecter l'immuabilité. Code actuel : const initialState = { count: 0 }; function counterReducer(state = initialState, action) { switch (action.type) { case 'INCREMENT': state.count += 1; return state; default: return state; } } Livrable attendu : Corriger le reducer afin de respecter le principe d'immuabilité et garantir une mise à jour correcte du state.

Contexte : Une application dispatch une action pour ajouter un utilisateur. Le Problème : Le reducer ne reçoit pas correctement les données car l'action est mal formée. Contraintes : Respecter la structure standard { type, payload }. Code actuel : const addUser = (user) => ({ user: user }); Livrable attendu : Corriger l'action afin qu'elle respecte les conventions Redux et puisse être traitée correctement par le reducer.

Contexte : Une application doit déclencher une augmentation du compteur via bouton. Le Problème : L'action est dispatchée directement sous forme d'objet inline. Contraintes : Créer un action creator dédié. Livrable attendu : Implémenter un action creator réutilisable retournant une action de type INCREMENT.

Contexte : Un reducer retourne undefined lorsqu'une action inconnue est dispatchée. Le Problème : Cela provoque des erreurs dans le store. Contraintes : Toujours retourner l'état courant par défaut. Livrable attendu : Corriger le reducer afin qu'il retourne systématiquement un état valide.

Contexte : Une application front-end doit centraliser son état global pour gérer un panier simple. Le Problème : Aucun store Redux n'est encore configuré. Contraintes : Utiliser createStore natif Redux. Aucun middleware. Livrable attendu : Mettre en place un store Redux minimal avec un reducer simple permettant d'ajouter un article au panier.

Contexte : Une application doit gérer une liste de tâches via Redux. Le Problème : Aucun reducer n'est implémenté pour ajouter ou supprimer des éléments. Contraintes : Respecter l'immuabilité de l'état. Livrable attendu : Développer un reducer capable d'ajouter et supprimer des tâches à partir d'actions dédiées.

Contexte : Une application doit permettre de réinitialiser un formulaire global. Le Problème : Aucun mécanisme ne permet de revenir à l'état initial. Contraintes : Ajouter une action RESET proprement gérée dans le reducer. Livrable attendu : Implémenter une action et un case correspondant permettant de restaurer l'état initial.

Contexte : Un reducer met à jour un objet profondément imbriqué dans le state. Le Problème : L'état est muté accidentellement via modification directe d'un sous-objet. Code actuel : case 'UPDATE_PROFILE': state.user.profile.name = action.payload; return state; Contraintes : Respecter strictement l'immuabilité. Livrable attendu : Refactoriser la mise à jour en utilisant des copies immuables pour éviter toute mutation directe.

Contexte : Un composant calcule dynamiquement des données dérivées à partir du store. Le Problème : Les calculs sont répétés à chaque rendu, impactant les performances. Contraintes : Utiliser reselect pour créer un selector mémoïsé. Livrable attendu : Implémenter un selector performant recalculant uniquement lorsque les dépendances changent.

Contexte : Une application doit charger une liste d'utilisateurs depuis une API distante. Le Problème : Le reducer tente de gérer directement la logique asynchrone, ce qui viole les principes Redux. Contraintes : Utiliser redux-thunk pour gérer les appels asynchrones. Livrable attendu : Mettre en place une action asynchrone permettant de gérer loading, success et error proprement dans le store.

Contexte : Une application Redux doit tracer toutes les actions dispatchées pour audit interne. Le Problème : Aucun mécanisme centralisé ne permet d'intercepter les actions. Contraintes : Créer un middleware Redux personnalisé sans librairie externe. Livrable attendu : Implémenter un middleware interceptant chaque action, affichant son type et l'état précédent/suivant.

Contexte : Les erreurs API sont gérées localement dans chaque composant. Le Problème : Les messages d'erreur sont incohérents et difficiles à tracer. Contraintes : Centraliser la gestion des erreurs dans Redux. Livrable attendu : Concevoir une slice ou reducer dédié aux erreurs permettant une gestion cohérente et globale.

Contexte : Plusieurs appels API déclenchent des états de chargement indépendants. Le Problème : L'application affiche des loaders incohérents selon les sections. Contraintes : Centraliser la gestion des états de chargement dans Redux. Livrable attendu : Concevoir une stratégie permettant de gérer un état de loading global ou par slice de manière cohérente.

Contexte : Une application stocke des données utilisateurs et leurs commandes dans une structure profondément imbriquée. Le Problème : Les mises à jour deviennent complexes et coûteuses en performances. Contraintes : Repenser la structure du state en adoptant une normalisation. Livrable attendu : Refactoriser le state en utilisant une structure normalisée (entities, ids) afin de simplifier les mises à jour et accès aux données.

Contexte : Une application grandissante commence à accumuler de nombreux reducers et actions. Le Problème : La structure actuelle du store manque d'organisation claire. Contraintes : Mettre en place une architecture modulaire par feature. Livrable attendu : Proposer une organisation du projet Redux par feature (feature-based structure) pour améliorer la scalabilité.

Contexte : Vous reprenez une application Redux dont un seul reducer gère utilisateurs, panier et notifications. Le Problème : Le reducer devient difficile à maintenir, avec un switch volumineux et des dépendances croisées entre états. Contraintes : Utiliser combineReducers pour séparer la logique. Aucun middleware externe requis. Code actuel : function appReducer(state = initialState, action) { switch(action.type) { case 'ADD_USER': case 'REMOVE_USER': case 'ADD_TO_CART': case 'CLEAR_CART': // logique mélangée return state; default: return state; } } Livrable attendu : Refactoriser en plusieurs reducers spécialisés (user, cart, notification) combinés via combineReducers.

Contexte : Un projet utilise Redux classique avec beaucoup de boilerplate. Le Problème : Les actions et reducers sont verbeux et répétitifs. Contraintes : Migrer vers Redux Toolkit sans modifier la logique métier. Livrable attendu : Refactoriser le store en utilisant createSlice et configureStore pour simplifier l'architecture.

Contexte : L'équipe souhaite analyser l'évolution du state lors d'actions successives. Le Problème : Aucun mécanisme interne ne permet de rejouer ou revenir à un état précédent sans outil externe. Contraintes : Implémenter un enhancer Redux personnalisé. Livrable attendu : Développer un store enhancer permettant de stocker l'historique des états et de naviguer entre eux (undo/redo).

Contexte : L'application dépend fortement d'appels API critiques. Le Problème : Les erreurs réseau ne sont pas gérées de manière centralisée et aucune stratégie de retry n'est implémentée. Contraintes : Implémenter la logique via middleware personnalisé sans librairie externe. Livrable attendu : Concevoir un middleware capable d'intercepter les erreurs, de centraliser leur gestion et d'implémenter une stratégie de retry contrôlée.

Contexte : Vous travaillez sur une application SaaS de grande taille dont le store Redux devient massif et difficile à maintenir. Le Problème : Tous les reducers sont enregistrés au démarrage, même pour des fonctionnalités rarement utilisées, ce qui alourdit le bundle et complique la maintenance. Contraintes : Utiliser Redux Toolkit et permettre l'injection dynamique de reducers (code splitting). Aucun framework supplémentaire. Livrable attendu : Proposer une architecture permettant le lazy loading de slices Redux par feature avec injection dynamique dans le store.

Contexte : Une application permet la modification immédiate de données avant confirmation serveur. Le Problème : En cas d'échec API, l'état reste incohérent. Contraintes : Implémenter une stratégie d'optimistic update avec rollback via Redux. Livrable attendu : Concevoir un mécanisme permettant d'appliquer une mise à jour optimiste puis d'annuler les modifications en cas d'erreur serveur.

Contexte : L'application effectue plusieurs appels API pouvant être déclenchés rapidement (recherche en temps réel). Le Problème : Les réponses arrivent dans le désordre et écrasent parfois des données plus récentes. Contraintes : Créer un middleware personnalisé capable d'annuler ou d'ignorer les requêtes obsolètes. Aucun outil externe comme redux-saga. Livrable attendu : Implémenter un middleware gérant les requêtes concurrentes et assurant la cohérence des données dans le store.

Contexte : L'application recharge fréquemment les mêmes données API. Le Problème : Les appels redondants dégradent les performances et augmentent la latence. Contraintes : Mettre en place un système de cache côté Redux avec stratégie d'invalidation. Livrable attendu : Concevoir une logique permettant de stocker les réponses API, vérifier leur validité et invalider le cache selon des règles définies.

Contexte : Une application multi-rôles doit afficher ou masquer certaines fonctionnalités selon les droits utilisateurs. Le Problème : La logique de permissions est dispersée dans plusieurs composants. Contraintes : Centraliser la gestion des permissions dans Redux. Livrable attendu : Concevoir une slice dédiée aux permissions et des selectors sécurisés permettant un contrôle d'accès cohérent dans toute l'application.

Contexte : Une application complexe contient de nombreux effets secondaires (API, logs, analytics). Le Problème : Les side effects sont parfois déclenchés directement dans les composants, rendant l'architecture fragile. Contraintes : Centraliser tous les side effects via middleware personnalisé ou createAsyncThunk. Livrable attendu : Proposer une architecture robuste garantissant que tous les effets secondaires transitent uniquement par une couche middleware contrôlée.

Contexte : Une application utilise Redux classique avec beaucoup de boilerplate, actions constantes séparées et reducers volumineux. Le Problème : La structure actuelle ralentit le développement et augmente les risques d'erreur. Contraintes : Migrer vers Redux Toolkit (createSlice, createAsyncThunk) sans modifier la logique métier. Livrable attendu : Refactoriser complètement l'architecture pour réduire le boilerplate et améliorer la lisibilité tout en conservant le comportement existant.

Contexte : Une application manipule des milliers d'entités (utilisateurs, commandes, produits). Le Problème : Les re-renders deviennent fréquents et les calculs dérivés ralentissent l'interface. Contraintes : Utiliser une normalisation stricte du state et des selectors mémoïsés avec reselect. Livrable attendu : Refactoriser le state en structure normalisée et créer des selectors optimisés pour minimiser les recalculs et re-renders.