Cas pratiques React

Contexte : L'équipe design souhaite uniformiser l'affichage des cartes produits. Le Problème : Les développeurs dupliquent le même JSX dans plusieurs pages. Contraintes : Créer un composant réutilisable acceptant title et description en props. Livrable attendu : Implémenter un composant Card simple et démontrer son utilisation avec au moins deux instances différentes.

Contexte : Une application interne affiche un message de bienvenue uniquement si l'utilisateur est connecté. Le Problème : Le message ne s'affiche jamais même lorsque la variable est à true. Contraintes : Conserver la logique actuelle et corriger uniquement l'erreur de rendu JSX. Code actuel : function Welcome() { const [isLogged, setIsLogged] = React.useState(true); return ( <div> {if(isLogged) {<p>Bienvenue</p>}} </div> ); } Livrable attendu : Corriger la syntaxe JSX afin que le message s'affiche correctement lorsque l'utilisateur est connecté.

Contexte : Vous intervenez sur une application interne permettant d'afficher une liste de tâches saisies par les collaborateurs. Le Problème : Lorsqu'une nouvelle tâche est ajoutée, l'interface ne se met pas toujours à jour correctement et certaines tâches disparaissent. Contraintes : Vous devez corriger le composant sans modifier son architecture globale. Aucune librairie externe n'est autorisée. Utilisation exclusive des hooks React. Code actuel : function TaskList() { const [tasks, setTasks] = React.useState([]); const addTask = () => { tasks.push("Nouvelle tâche"); setTasks(tasks); }; return ( <div> <button onClick={addTask}>Ajouter</button> <ul> {tasks.map((t, i) => ( <li key={i}>{t}</li> ))} </ul> </div> ); } Livrable attendu : Corriger la gestion du state pour que chaque ajout déclenche correctement un nouveau rendu sans effets de bord.

Contexte : Votre équipe souhaite standardiser l'affichage des sections dépliables dans plusieurs pages. Le Problème : Aucun composant générique n'existe pour gérer l'ouverture et la fermeture d'un bloc. Contraintes : Utiliser un composant fonctionnel avec useState. Aucun style complexe requis. Le composant doit accepter des children. Livrable attendu : Développer un composant Toggle qui affiche un bouton et affiche ou masque dynamiquement son contenu en fonction de l'état interne.

Contexte : Une équipe marketing souhaite limiter les descriptions produits à 150 caractères. Le Problème : Aucun indicateur visuel n'existe pour informer l'utilisateur du nombre de caractères restants. Contraintes : Utiliser useState pour suivre le texte. Afficher le nombre de caractères restants dynamiquement. Livrable attendu : Développer un composant avec textarea affichant le nombre de caractères utilisés et restants en temps réel.

Contexte : Une équipe affiche une liste de produits dynamiques issue d'un tableau local. Le Problème : Lors de suppressions d'éléments, l'affichage devient incohérent et certains éléments changent de position de manière inattendue. Contraintes : Vous devez corriger uniquement la gestion des clés dans le rendu de liste. Code actuel : function Products() { const [items] = React.useState([ { id: 1, name: "A" }, { id: 2, name: "B" } ]); return ( <ul> {items.map((item, index) => ( <li key={index}>{item.name}</li> ))} </ul> ); } Livrable attendu : Modifier la clé utilisée afin de garantir un rendu stable et prévisible lors des modifications futures.

Contexte : Une application affiche une liste statique de collaborateurs. Le Problème : Les utilisateurs souhaitent filtrer les noms en temps réel via un champ de recherche. Contraintes : Utiliser useState pour gérer la recherche. Pas de librairie externe. Filtrage insensible à la casse. Livrable attendu : Créer un composant contenant un input et une liste filtrée dynamiquement en fonction de la valeur saisie.

Contexte : Une démonstration pédagogique nécessite un compteur simple pour illustrer la gestion du state. Le Problème : Aucun composant n'existe pour incrémenter et réinitialiser une valeur. Contraintes : Utiliser exclusivement useState. Deux boutons : incrémenter et reset. Livrable attendu : Créer un composant Counter affichant la valeur courante et permettant d'incrémenter et de remettre à zéro proprement.

Contexte : Vous reprenez un composant chargé d'afficher un compteur synchronisé avec le titre du navigateur. Le Problème : L'application devient lente et semble entrer dans une boucle infinie de rendu. Contraintes : Vous devez corriger le problème en utilisant correctement le tableau de dépendances de useEffect. Code actuel : function TitleCounter() { const [count, setCount] = React.useState(0); React.useEffect(() => { document.title = "Compteur " + count; setCount(count + 1); }); return <p>{count}</p>; } Livrable attendu : Corriger l'effet pour éviter les rendus infinis tout en conservant la mise à jour dynamique du titre.

Contexte : Une équipe RH utilise un petit formulaire React pour collecter des noms de candidats. Le Problème : Le champ texte ne reflète pas correctement la saisie utilisateur et reste vide malgré les frappes clavier. Contraintes : Vous devez conserver un composant fonctionnel simple avec useState. Pas de librairie tierce. Code actuel : function Form() { const [name, setName] = React.useState(""); return ( <div> <input value={name} onChange={() => setName(name)} /> <p>{name}</p> </div> ); } Livrable attendu : Corriger la gestion de l'événement onChange afin que le champ soit correctement contrôlé et reflète la saisie en temps réel.

Contexte : Plusieurs modules du projet nécessitent l'affichage de fenêtres modales pour confirmer des actions critiques. Le Problème : Aucun composant centralisé n'existe et chaque équipe implémente sa propre logique. Contraintes : Créer un composant générique contrôlé par props open et onClose. Livrable attendu : Développer un composant Modal réutilisable capable d'afficher du contenu dynamique et de se fermer correctement.

Contexte : Votre équipe souhaite factoriser la logique de gestion de formulaires utilisée dans plusieurs modules internes. Le Problème : Chaque formulaire du projet duplique la même logique de gestion du state et des événements. Contraintes : Vous devez créer un hook personnalisé réutilisable sans dépendance externe. Livrable attendu : Implémenter un hook useForm permettant de gérer dynamiquement les champs, la mise à jour du state et la réinitialisation du formulaire.

Contexte : Une application affiche une liste de cartes produits avec un composant enfant pour chaque carte. Le Problème : À chaque modification du parent, tous les composants enfants se re-rendent, même si leurs props n'ont pas changé. Contraintes : Vous devez optimiser le rendu sans changer l'architecture globale. Utilisation autorisée de React.memo. Code actuel : function Card({ product }) { return <div>{product.name}</div>; } function ProductList({ products }) { const [count, setCount] = React.useState(0); return ( <div> <button onClick={() => setCount(count + 1)}>Update</button> {products.map(p => ( <Card key={p.id} product={p} /> ))} </div> ); } Livrable attendu : Optimiser le composant pour éviter les re-rendus inutiles des cartes.

Contexte : Une application interne affiche une liste de produits avec un total calculé dynamiquement pour le reporting. Le Problème : Le total affiché ne correspond pas toujours à la somme réelle des produits après mise à jour du panier. Contraintes : Vous devez corriger le calcul sans ajouter de librairie externe. Utilisation autorisée de useMemo si nécessaire. Code actuel : function Cart({ items }) { const [total, setTotal] = React.useState(0); React.useEffect(() => { setTotal(items.reduce((acc, item) => acc + item.price, 0)); }, []); return <div>Total : {total}</div>; } Livrable attendu : Corriger la logique pour que le total se mette à jour correctement lorsque items change.

Contexte : Une application React consomme une API interne dont la disponibilité n'est pas garantie. Le Problème : En cas d'erreur réseau, l'application plante ou n'affiche aucun message utilisateur. Contraintes : Utiliser useState pour gérer loading et error. Aucun outil externe. Livrable attendu : Implémenter un composant robuste affichant un loader, les données en cas de succès et un message d'erreur clair en cas d'échec.

Contexte : Vous reprenez un formulaire React utilisé pour créer des profils utilisateurs dans un back-office. Le Problème : Les champs semblent écraser les valeurs précédentes lors de la saisie, rendant les données incohérentes. Contraintes : Vous devez conserver un seul state global pour le formulaire. Aucune librairie externe. Code actuel : function ProfileForm() { const [form, setForm] = React.useState({ name: "", email: "" }); const handleChange = (e) => { setForm({ [e.target.name]: e.target.value }); }; return ( <form> <input name="name" onChange={handleChange} /> <input name="email" onChange={handleChange} /> </form> ); } Livrable attendu : Corriger la gestion du state afin que chaque champ mette à jour uniquement sa propre valeur sans supprimer les autres.

Contexte : Une plateforme interne affiche une liste d'utilisateurs avec filtres par rôle et statut. Le Problème : Les filtres doivent fonctionner simultanément et rester synchronisés avec l'interface. Contraintes : Utiliser useState pour stocker les filtres et optimiser les recalculs. Livrable attendu : Développer un composant permettant d'appliquer plusieurs filtres combinés à une liste tout en maintenant de bonnes performances.

Contexte : Le produit doit proposer un thème clair et un thème sombre pour améliorer l'expérience utilisateur. Le Problème : Aucun mécanisme global n'existe pour partager le thème entre les composants. Contraintes : Utiliser React Context pour gérer l'état global. Pas de librairie externe. Livrable attendu : Implémenter un ThemeContext permettant de basculer entre deux thèmes et d'appliquer dynamiquement les styles dans l'application.

Contexte : Une équipe produit souhaite permettre le tri dynamique d'une liste d'articles par prix ou par nom. Le Problème : Le tri actuel provoque des re-rendus inutiles et dégrade les performances lorsque la liste dépasse 500 éléments. Contraintes : Vous devez implémenter une solution optimisée sans librairie externe. L'utilisation de useMemo est autorisée. Livrable attendu : Créer un composant React permettant de trier dynamiquement une liste importante en limitant les recalculs inutiles.

Contexte : Vous reprenez un module React chargé d'afficher une liste d'utilisateurs provenant d'une API interne utilisée par l'équipe commerciale. Le Problème : À chaque mise à jour des données, le composant relance automatiquement un nouvel appel API, provoquant une boucle infinie de requêtes et une surcharge du backend. Contraintes : Vous devez conserver l'utilisation de useState et useEffect. Aucune librairie externe n'est autorisée. Le comportement doit rester asynchrone et compatible avec React 18. Code actuel : function Users() { const [users, setUsers] = React.useState([]); React.useEffect(() => { fetch("/api/users") .then(res => res.json()) .then(data => setUsers(data)); }, [users]); return ( <ul> {users.map(user => ( <li key={user.id}>{user.name}</li> ))} </ul> ); } Livrable attendu : Corriger la dépendance du useEffect afin d'éviter les appels répétés tout en garantissant un chargement initial correct.

Contexte : Une application métier comporte plusieurs écrans interconnectés partageant un state complexe. Le Problème : La gestion via useState devient difficilement maintenable et entraîne des effets de bord. Contraintes : Aucun Redux, Zustand ou autre librairie externe. Utilisation possible de useReducer et Context. Livrable attendu : Proposer une architecture robuste combinant useReducer et Context pour centraliser et structurer l'état global.

Contexte : Une application utilise React Context pour gérer un state global contenant utilisateur, thème et paramètres. Le Problème : À chaque modification mineure, l'ensemble des composants consommateurs se re-rendent inutilement. Contraintes : Vous devez conserver Context API sans ajouter Redux ou autre librairie externe. Optimisation via séparation ou memoization autorisée. Code actuel : const AppContext = React.createContext(); function AppProvider({ children }) { const [state, setState] = React.useState({ theme: "light", user: null }); return ( <AppContext.Provider value={{ state, setState }}> {children} </AppContext.Provider> ); } Livrable attendu : Refactoriser la structure pour limiter les re-rendus inutiles des composants consommateurs.

Contexte : Un hook personnalisé useFetch est utilisé pour charger des données selon un paramètre dynamique. Le Problème : Lors de changements rapides du paramètre, les réponses arrivent dans le désordre et écrasent les données plus récentes. Contraintes : Vous devez corriger la condition de concurrence sans librairie externe. Code actuel : function useFetch(url) { const [data, setData] = React.useState(null); React.useEffect(() => { fetch(url) .then(res => res.json()) .then(result => setData(result)); }, [url]); return data; } Livrable attendu : Implémenter une solution empêchant l'écrasement des données par des réponses obsolètes.

Contexte : L'équipe souhaite générer des formulaires dynamiquement à partir d'un schéma JSON fourni par le backend. Le Problème : Les champs, validations et types doivent être interprétés dynamiquement côté client. Contraintes : Aucune librairie externe de formulaire autorisée. Architecture flexible requise. Livrable attendu : Concevoir un composant React capable de générer dynamiquement des champs à partir d'une configuration JSON et de gérer leur validation.

Contexte : Vous devez concevoir la couche front-end d'une authentification basée sur JWT pour un SaaS interne. Le Problème : L'application doit gérer le stockage du token, le rafraîchissement automatique et la protection des routes. Contraintes : Aucun framework externe d'authentification autorisé. Utilisation de Context et hooks personnalisés recommandée. Livrable attendu : Concevoir une architecture React permettant login, logout, stockage sécurisé du token et protection conditionnelle des routes.

Contexte : Une application modulaire charge plusieurs sections rarement utilisées. Le Problème : Le bundle principal est trop volumineux et impacte le temps de chargement initial. Contraintes : Utiliser React.lazy et Suspense. Aucun outil externe de code splitting autorisé. Livrable attendu : Implémenter un chargement différé de composants avec gestion d'un fallback propre.

Contexte : Une application de dashboard interactif comporte de nombreux composants enfants recevant des fonctions en props. Le Problème : Les re-rendus sont fréquents car les callbacks sont recréés à chaque rendu du parent. Contraintes : Vous devez optimiser les performances via useCallback et memo sans altérer la logique métier. Livrable attendu : Refactoriser les composants pour limiter les recréations de fonctions et les re-rendus inutiles.

Contexte : Une application interne permet de rechercher parmi plus de 10 000 enregistrements côté client. Le Problème : Chaque frappe clavier déclenche un filtrage complet de la liste, provoquant des ralentissements significatifs. Contraintes : Vous devez implémenter une logique de debounce sans librairie externe et optimiser les recalculs avec useMemo ou useCallback. Livrable attendu : Développer un composant performant intégrant un champ de recherche avec debounce et optimisation des rendus.

Contexte : Vous reprenez une application React connectée à un WebSocket interne pour afficher en temps réel des transactions financières. Le Problème : À chaque mise à jour, plusieurs connexions WebSocket sont ouvertes, provoquant des fuites mémoire et des doublons dans l'affichage. Contraintes : Vous devez corriger la gestion du cycle de vie sans ajouter de librairie externe. L'utilisation de useEffect et useRef est autorisée. La connexion doit être proprement fermée lors du démontage. Code actuel : function LiveFeed() { const [messages, setMessages] = React.useState([]); React.useEffect(() => { const socket = new WebSocket("wss://example.com/feed"); socket.onmessage = (event) => { setMessages(prev => [...prev, event.data]); }; }); return ( <ul> {messages.map((msg, i) => ( <li key={i}>{msg}</li> ))} </ul> ); } Livrable attendu : Stabiliser la connexion WebSocket pour qu'elle ne soit ouverte qu'une seule fois et correctement nettoyée.

Contexte : Une application doit afficher plus de 50 000 éléments dans une liste scrollable. Le Problème : Le rendu actuel provoque des blocages et une consommation mémoire excessive. Contraintes : Aucune librairie externe de virtualisation autorisée. Implémentation maison requise. Livrable attendu : Concevoir un composant de virtualisation simple affichant uniquement les éléments visibles selon la position du scroll.