Cas pratiques React Native

Contexte : Une application récupère des données depuis une API distante. Le Problème : En cas d’erreur réseau, l’application plante ou reste bloquée. Extrait logique actuelle : fetch(url) .then(res => res.json()) .then(data => setData(data)); Contraintes : Ajouter gestion des erreurs avec catch. Implémenter état loading et état error. Garantir stabilité de l’interface. Livrable attendu : Corriger l’appel API afin de gérer correctement erreurs réseau et afficher message utilisateur adapté.

Contexte : Un bouton de soumission doit être actif uniquement si le formulaire est valide. Le Problème : Le bouton reste actif même lorsque les champs sont vides. Extrait logique actuelle : <Button title="Submit" onPress={handleSubmit} /> Contraintes : Conditionner propriété disabled selon validité des champs. Mettre à jour état dynamiquement. Livrable attendu : Corriger la logique afin que le bouton soit activé uniquement lorsque toutes les conditions de validation sont respectées.

Contexte : Une application affiche un compteur simple incrémenté via un bouton. Le Problème : La valeur interne change mais l’interface ne se met pas à jour correctement. Extrait logique actuelle : let counter = 0; function increment() { counter++; } Contraintes : Utiliser correctement useState pour gérer la valeur du compteur. Garantir que le rendu se déclenche automatiquement lors du changement d’état. Livrable attendu : Corriger le composant afin que l’incrémentation mette immédiatement à jour l’interface utilisateur.

Contexte : L’application fonctionne correctement sur grand écran mais présente débordements sur petits appareils. Le Problème : Certains éléments dépassent la largeur disponible. Extrait logique actuelle : <View style={{ flexDirection: 'row' }}> <Text>{longText}</Text> </View> Contraintes : Utiliser flexbox correctement. Ajouter flexWrap ou ajuster flex. Tester sur différentes tailles d’écran. Livrable attendu : Corriger le layout afin d’assurer affichage responsive sans débordement.

Contexte : Une application affiche une liste dynamique d’éléments. Le Problème : Une erreur apparaît concernant la propriété key. Extrait logique actuelle : <FlatList data={items} renderItem={({ item }) => <Text>{item.name}</Text>} /> Contraintes : Ajouter keyExtractor adapté. Garantir unicité des clés. Éviter usage d’index si possible. Livrable attendu : Corriger l’implémentation afin de supprimer l’erreur et assurer rendu stable de la liste.

Contexte : Une startup développe sa première application mobile en React Native et souhaite mettre en place un écran de connexion simple. Le Problème : Aucun formulaire n’est encore implémenté et l’équipe veut une validation basique côté client avant intégration backend. Contraintes : Utiliser View, TextInput et Button. Gérer l’état local avec useState. Valider que l’email n’est pas vide et que le mot de passe contient au moins 6 caractères. Afficher un message d’erreur clair en cas d’entrée invalide. Livrable attendu : Implémenter un écran de connexion complet avec gestion d’état locale et validation utilisateur fonctionnelle.

Contexte : Une application mobile doit permettre création de compte utilisateur. Le Problème : Aucun mécanisme de validation n’est actuellement implémenté. Contraintes : Utiliser useState pour gérer champs. Vérifier cohérence mot de passe et confirmation. Afficher messages d’erreur sous chaque champ. Livrable attendu : Développer un formulaire d’inscription complet avec validation et retour utilisateur clair.

Contexte : Une application doit permettre à l’utilisateur de sélectionner un élément dans une liste. Le Problème : Aucun mécanisme de sélection n’est actuellement implémenté. Contraintes : Utiliser FlatList. Gérer état sélection via useState. Modifier style de l’élément sélectionné. Livrable attendu : Implémenter une liste interactive permettant sélection et désélection avec retour visuel clair.

Contexte : L’application doit respecter une charte graphique cohérente. Le Problème : Les styles sont définis de manière répétitive dans chaque composant. Contraintes : Centraliser couleurs et styles principaux. Utiliser StyleSheet. Éviter duplication inutile. Livrable attendu : Mettre en place un système simple de styles partagés assurant cohérence visuelle globale.

Contexte : L’application nécessite un écran d’accueil et un écran de détail accessibles via navigation. Le Problème : Aucun système de navigation n’est encore en place. Contraintes : Utiliser React Navigation. Créer deux écrans distincts. Implémenter navigation via un bouton. Permettre retour arrière simple. Livrable attendu : Mettre en place une navigation fonctionnelle entre deux écrans avec passage éventuel d’un paramètre simple.

Contexte : Une liste d’éléments affiche des composants enfants lourds. Le Problème : Chaque modification d’état provoque re-render de tous les items. Extrait logique actuelle : const Item = ({ item }) => { return <View>...</View>; }; Sans optimisation. Contraintes : Utiliser React.memo. Stabiliser props via useCallback ou useMemo. Mesurer réduction des re-renders. Livrable attendu : Optimiser le composant afin d’améliorer significativement performance du rendu.

Contexte : Un formulaire multi-étapes réparti sur plusieurs écrans perd les données lors du retour arrière. Le Problème : Les valeurs sont stockées uniquement dans l’état local du composant. Extrait logique actuelle : const [formData, setFormData] = useState({}); Contraintes : Centraliser état du formulaire. Persister données temporairement. Maintenir cohérence entre étapes. Livrable attendu : Proposer une gestion structurée permettant conservation fiable des données sur navigation multi-écrans.

Contexte : Un écran utilise un listener d’événement (AppState ou Dimensions). Le Problème : Après navigation répétée, l’application ralentit. Extrait logique actuelle : useEffect(() => { Dimensions.addEventListener('change', handler); }, []); Sans suppression. Contraintes : Supprimer listener dans fonction de cleanup. Vérifier absence de fuite mémoire. Tester navigation répétée. Livrable attendu : Corriger la gestion du cycle de vie afin d’éviter accumulation de listeners.

Contexte : Après connexion, l’utilisateur est parfois redirigé vers un écran incorrect. Le Problème : La logique de navigation dépend d’un état non synchronisé. Extrait logique actuelle : if (isLoggedIn) { navigation.navigate('Home'); } Sans attendre mise à jour d’état. Contraintes : Synchroniser mise à jour état et navigation. Éviter navigation prématurée. Tester transitions. Livrable attendu : Corriger la logique afin d’assurer navigation fiable et cohérente.

Contexte : Un écran charge des données utilisateur au montage. Le Problème : L’API est appelée plusieurs fois involontairement. Extrait logique actuelle : useEffect(() => { fetchData(); }); Contraintes : Ajouter tableau de dépendances correct. Éviter boucle infinie. Gérer état loading proprement. Livrable attendu : Corriger l’implémentation afin que l’appel API ne soit exécuté qu’au moment approprié.

Contexte : Une application React Native de gestion de profil utilisateur commence à inclure plusieurs écrans partageant les mêmes informations (authentification, préférences, thème). Le Problème : L’état est actuellement passé via props drilling, rendant le code difficile à maintenir et à faire évoluer. Contraintes : Utiliser React Context pour centraliser l’état global. Séparer logique métier et composants UI. Éviter les re-renders inutiles. Maintenir structure claire et testable. Livrable attendu : Implémenter un système de state management basé sur Context API permettant partage propre et scalable des données entre écrans.

Contexte : Une application nécessite simulation d’authentification avant connexion à backend réel. Le Problème : Aucune gestion centralisée de session n’est mise en place. Contraintes : Stocker token localement. Mettre en place contexte global d’authentification. Rediriger utilisateur selon état connecté. Livrable attendu : Implémenter un système structuré d’authentification simulée avec gestion propre de session et redirections.

Contexte : L’application doit permettre à l’utilisateur de choisir entre thème clair et sombre. Le Problème : Les styles sont statiques et ne s’adaptent pas dynamiquement. Contraintes : Utiliser Context API pour stocker thème. Adapter styles dynamiquement. Assurer cohérence sur tous les écrans. Livrable attendu : Implémenter un système de thème dynamique permettant bascule fluide entre modes clair et sombre.

Contexte : L’application effectue plusieurs appels réseau dans différents écrans. Le Problème : La gestion d’erreurs est dupliquée et incohérente. Contraintes : Centraliser logique d’appel API. Standardiser format des erreurs. Afficher message utilisateur cohérent. Livrable attendu : Concevoir une couche d’abstraction réseau permettant gestion centralisée et uniforme des erreurs API.

Contexte : Une application affiche un grand volume d’articles récupérés via API. Le Problème : Tous les articles sont chargés d’un coup, provoquant lenteur et consommation mémoire excessive. Contraintes : Implémenter pagination côté client. Utiliser onEndReached de FlatList. Gérer indicateur de chargement en bas de liste. Éviter double chargement. Livrable attendu : Développer un système de pagination fluide améliorant performance et expérience utilisateur.

Contexte : Une application comporte plusieurs niveaux de navigation et des sections protégées. Le Problème : La gestion des redirections selon état d’authentification devient instable et difficile à maintenir. Contraintes : Centraliser logique d’authentification. Implémenter redirections conditionnelles propres. Maintenir cohérence du back stack. Livrable attendu : Proposer une architecture de navigation robuste permettant gestion claire des routes publiques et protégées.

Contexte : Une application mobile évolue rapidement avec plusieurs modules (authentification, paiement, notifications) et une équipe de développeurs grandissante. Le Problème : Le code mélange composants UI, logique métier et appels réseau, rendant les tests et la maintenance complexes. Contraintes : Mettre en place une séparation claire entre présentation, logique métier et accès aux données. Introduire une couche de services réutilisables. Assurer testabilité indépendante des composants UI. Éviter dépendances circulaires. Livrable attendu : Proposer une architecture structurée et scalable incluant organisation des dossiers, responsabilités des couches et exemple de flux complet entre écran et service.

Contexte : Une application critique nécessite validation continue des fonctionnalités principales. Le Problème : Aucune stratégie de tests unitaires n’est en place pour la logique métier. Contraintes : Séparer logique métier des composants UI. Mettre en place tests unitaires. Simuler dépendances réseau via mocks. Livrable attendu : Proposer une stratégie complète de tests automatisés garantissant fiabilité des composants clés indépendamment de l’interface utilisateur.

Contexte : Un écran déclenche plusieurs appels API parallèles pour charger données utilisateur et commandes. Le Problème : Les réponses arrivent dans un ordre imprévisible et provoquent des incohérences d’état. Extrait logique actuelle : fetchUser(); fetchOrders(); Sans coordination. Contraintes : Synchroniser les appels asynchrones. Gérer erreurs partielles. Garantir cohérence finale de l’état global affiché. Livrable attendu : Corriger la gestion des appels concurrents afin d’assurer fiabilité des données et stabilité de l’interface.

Contexte : Une liste complexe contient plusieurs composants interactifs. Le Problème : Chaque modification d’état global provoque re-render de tous les éléments, ralentissant fortement l’application. Extrait logique actuelle : const items = data.map(item => <Item key={item.id} data={item} />); Sans optimisation. Contraintes : Utiliser React.memo. Stabiliser callbacks via useCallback. Limiter dépendances inutiles. Livrable attendu : Optimiser le rendu afin de réduire significativement les re-renders et améliorer fluidité globale.

Contexte : L’application stocke un token d’authentification localement. Le Problème : Après expiration du token, certaines parties restent accessibles. Extrait logique actuelle : if (token) { navigation.navigate('Home'); } Sans validation de validité. Contraintes : Vérifier expiration du token. Centraliser gestion de session. Forcer déconnexion si session invalide. Livrable attendu : Corriger la gestion d’authentification afin d’assurer sécurité et cohérence de session utilisateur.

Contexte : L’application utilise un store global pour gérer données utilisateur et commandes. Le Problème : Des mises à jour simultanées créent des états incohérents. Extrait logique actuelle : dispatch(updateUser(data)); dispatch(updateOrders(data)); Sans coordination. Contraintes : Synchroniser mises à jour critiques. Garantir atomicité logique. Tester scénarios concurrents. Livrable attendu : Corriger la gestion d’état afin d’éviter conditions de course et garantir cohérence globale des données.

Contexte : Un écran utilise setInterval pour rafraîchir des données périodiquement. Le Problème : Après navigation répétée, plusieurs timers continuent de tourner en arrière-plan. Extrait logique actuelle : useEffect(() => { setInterval(fetchData, 5000); }, []); Sans nettoyage. Contraintes : Nettoyer timer dans fonction de cleanup. Éviter duplication d’intervalles. Tester stabilité après navigation répétée. Livrable attendu : Corriger la gestion des timers afin d’éviter fuite mémoire et consommation excessive de ressources.

Contexte : L’application interroge fréquemment les mêmes ressources distantes. Le Problème : Les appels répétés augmentent latence et consommation réseau. Contraintes : Mettre en place cache local avec durée de validité configurable. Gérer invalidation automatique. Maintenir cohérence avec serveur. Livrable attendu : Concevoir un mécanisme de cache structuré améliorant performance tout en garantissant fiabilité des données affichées.

Contexte : Une application terrain doit fonctionner même sans connexion réseau stable. Le Problème : Les actions effectuées hors ligne sont perdues ou provoquent erreurs à la reconnexion. Contraintes : Mettre en place stockage local temporaire. Implémenter file d’attente d’actions. Synchroniser automatiquement à la reconnexion. Gérer conflits simples. Livrable attendu : Concevoir une architecture offline-first robuste garantissant persistance locale et synchronisation cohérente avec le serveur.