React Native Flow

Questions d'entretien

Longue liste React et JavaScript avec des réponses à survoler avant un entretien.

1Fondamentaux JavaScript

Quels sont les types de données primitifs et non primitifs ?

Primitifs : String, Number, Boolean, Null, Undefined, Symbol, BigInt.
Non primitifs : Objets, Tableaux (Arrays), Fonctions (types par référence).

Qu’est-ce que le passage par valeur et par référence ?

Par valeur : on transmet une copie de la valeur (primitifs).
Par référence : on transmet une référence à la donnée d’origine (objets).

Qu’est-ce que la portée (scope) lexicale ?

La portée est déterminée par l’emplacement physique du code ; les fonctions internes ont accès à la portée externe.

Qu’est-ce que le hoisting ?

Le comportement de JavaScript qui déplace les déclarations de variables et de fonctions au début de leur portée.

Qu’est-ce que la event loop en JavaScript ?

Elle gère les callbacks asynchrones en retirant des tâches de la file d’événements et en les exécutant une à une.

Quelles sont les fonctions pures et impures ?

Pures : pas d’effets de bord, même sortie pour une même entrée.
Impures : provoquent des effets de bord ou dépendent d’un état externe.

Que sont les fonctions d’ordre supérieur ?

Des fonctions qui prennent d’autres fonctions en arguments ou qui les renvoient.

Que sont les anagrammes ?

Deux chaînes qui contiennent les mêmes lettres, dans un ordre différent.

Quelle est la différence entre une fonction classique et une fonction fléchée ?

Fonctions classiques : elles ont leur propre this, peuvent être utilisées comme constructeurs, et sont hoistées.
Fonctions fléchées : elles héritent de this depuis la portée lexicale, ne peuvent pas être des constructeurs et ne sont pas hoistées.

Quelle est la différence entre une copie superficielle (shallow copy) et une copie profonde (deep copy) ?

La copie superficielle duplique uniquement la structure de premier niveau ; les objets imbriqués restent liés à l’original.
La copie profonde duplique tout récursivement, en créant des copies totalement indépendantes.

2Bases de React

Quelle est la différence entre les composants de classe et les composants fonctionnels ?

Classe : utilise les méthodes de cycle de vie, this et l’état.
Fonctionnel : utilise des hooks, une syntaxe plus simple et un code plus clair.

À quoi fait référence `this` dans React ?

Dans les composants de classe, this désigne l’instance de classe courante.

Quel est le cycle de vie d’un composant React ?

Montage, Mise à jour, Démontage (par exemple : componentDidMount, componentDidUpdate, componentWillUnmount).

Quels sont les composants contrôlés et non contrôlés ?

Contrôlés : les éléments de formulaire dont la valeur est gérée par l’état React.
Non contrôlés : c’est le DOM qui gère l’état via des refs.

3Optimisation & performance de React

Qu’est-ce que `useMemo` et `useCallback`, et quelle est la différence ?

useMemo met en cache le résultat d’une fonction.
useCallback met en cache la référence de la fonction.

Que sont les hooks personnalisés et comment influencent-ils les performances ?

Des fonctions réutilisables construites à partir de hooks ; elles améliorent la réutilisation du code, mais doivent être optimisées pour éviter les re-rendus inutiles.

Si je veux réduire les re-rendus, quelle est la meilleure approche ?

Utiliser React.memo, useMemo, useCallback, et éviter les mises à jour inutiles de l’état/props.

Quelles sont les principales causes des re-rendus ?

Changement d’état ou de props, re-rendu du composant parent, mises à jour du contexte.

Si une valeur change dans le composant parent et que je ne veux pas que l’enfant re-rende, que fais-tu ?

Envelopper l’enfant avec React.memo et éviter de passer de nouvelles références.

Qu’est-ce que `React.memo` ?

Un HOC qui mémorise un composant fonctionnel pour éviter les re-rendus tant que les props ne changent pas.

4Patterns React & concepts avancés

Que sont les composants d’ordre supérieur (HOC) et les fonctions d’ordre supérieur (HOF) ?

HOC : une fonction qui prend un composant et renvoie un nouveau composant.
HOF : des fonctions qui renvoient ou acceptent d’autres fonctions.

Qu’est-ce que `forwardRef` ?

Une API React pour transmettre un ref à travers un composant jusqu’au nœud du composant enfant.

5Gestion d'état React

Qu’est-ce que Context et expliquez son fonctionnement ?

Permet le partage d’un état global via Provider/Consumer ou via le hook useContext.

Qu’est-ce que Redux et expliquez son fonctionnement ?

Gestion centralisée de l’état. Flux : Action -> Reducer -> Store -> View.

Quel middleware utilise Redux ?

Une fonction qui intercepte les actions avant qu’elles n’arrivent aux reducers (par exemple : redux-thunk).

Quelle est la différence entre middleware et reducer dans Redux ?

Le middleware gère les effets secondaires ; le reducer met à jour l’état à partir des actions.

Qu’est-ce qui est mieux : Redux ou Context ?

Context est simple et adapté aux petites apps. Redux est préférable pour les apps grandes et complexes avec des besoins avancés de gestion d’état.

6Spécifique React Native

Quelle est la différence entre React et React Native ?

React : pour les applications web utilisant HTML/CSS/JS. React Native : pour les applications mobiles utilisant des composants natifs.

Qu’est-ce que l’architecture Fabric ?

Un nouveau moteur de rendu de React Native qui améliore les performances et la concurrence en unifiant les threads.

Que fait Hermes ?

Un moteur JavaScript léger optimisé pour React Native afin d’améliorer les performances, réduire la taille de l’application et améliorer le time-to-interactive.

Qu’est-ce que Babel dans React Native ?

Un compilateur JavaScript qui transpose le JavaScript moderne dans un code compatible avec des environnements plus anciens.

7APIs & Réseau

Axios vs Fetch – lequel est le meilleur et pourquoi ?

Axios a une syntaxe plus simple, gère le JSON par défaut, supporte les interceptors et peut annuler des requêtes.
Fetch est natif mais nécessite plus de boilerplate.

Quel est l’aspect principal de GraphQL ?

Les clients peuvent demander exactement ce dont ils ont besoin. Il utilise des requêtes et un schéma pour optimiser le chargement des données.

8Packaging d'app mobile

Que signifient APK et AAB ?

APK : Android Package. AAB : Android App Bundle.

Quelle est la différence principale entre APK et AAB ?

AAB est un format de publication ; le Play Store génère des APK par appareil, ce qui permet de réduire la taille de l’application.

9CI/CD & DevOps

Expliquez le processus des pipelines CI/CD.

CI : construction et tests automatisés à chaque commit. CD : déploiement automatique du code testé vers la production.

10Bonus : méthodes de tableau/boucle

Quelle est la différence entre `map` et `forEach` ?

map renvoie un nouveau tableau ; forEach ne renvoie rien (il sert aux effets de bord).

11Passerelle de paiement

Quelle est la différence entre une passerelle de paiement et un processeur de paiement (PSP) ?

Une passerelle de paiement est le service/l’API qui route les transactions de façon sécurisée (souvent en gérant le chiffrement et la tokenisation). Un processeur de paiement est l’entité qui traite réellement la transaction de carte via les réseaux (et les banques). En pratique, de nombreux PSP fournissent les deux.

Quel est le flux typique pour gérer des paiements dans React Native (intégration type Stripe) ?

1) L’app collecte les informations de paiement (données de carte) et envoie à votre backend des identifiants non sensibles.
2) Le backend crée un PaymentIntent/Charge et renvoie un client secret.
3) L’app confirme le paiement avec le client secret et une clé publishable.
4) Le backend finalise l’état de la commande via des webhooks.

Pourquoi ne faut-il jamais stocker des clés secrètes dans l’application mobile ?

Les apps mobiles ne sont pas totalement de confiance. Les clés secrètes peuvent être extraites du binaire ou interceptées. Garder les secrets côté backend réduit la fraude et aide à répondre aux exigences de sécurité/conformité.

Que sont les webhooks et pourquoi sont-ils essentiels pour connaître l’état du paiement ?

Les webhooks notifient votre backend des événements asynchrones (succès, échec, remboursements, retentatives). Ils sont la source de vérité pour l’état final du paiement (plutôt que de se fier uniquement au résultat côté client).

Comment gérer les retentatives de manière sûre lors de la création de paiements ?

Utilisez des clés d’idempotence côté backend pour éviter les doubles paiements en cas de requêtes répétées (timeouts ou retentatives côté client). Implémentez aussi des vérifications d’état de commande avant de réessayer.

Quel est un flux de remboursement sûr ?

Déclenchez les remboursements depuis le backend, enregistrez l’intention/la phase du remboursement dans votre base de données, puis mettez à jour l’UI/le statut de la commande via les webhooks de remboursement. Gérez les remboursements partiels et assurez la réconciliation après des délais.

12Pont natif

Quel est le but du native bridging dans React Native ?

Le bridging est la manière dont JavaScript communique avec du code natif (et dont les modules natifs renvoient des informations). Il permet d’appeler des API de plateforme depuis JS et d’exposer des fonctionnalités natives comme modules accessibles depuis JS ou comme composants.

Comment un module natif est-il exposé à JavaScript ?

Vous implémentez un module natif, vous l’enregistrez auprès du runtime React Native, puis vous définissez les signatures et paramètres des méthodes pour que le côté JS puisse l’appeler (et éventuellement émettre des événements). Dans la nouvelle architecture, specs/codegen génèrent des liaisons plus fortement typées.

Quand faut-il utiliser `NativeEventEmitter` (événements) plutôt que d’appeler une méthode native ?

Quand le côté natif produit des événements continus ou asynchrones (par exemple : mises à jour de localisation, Bluetooth, progression de téléchargement). Les événements sont meilleurs que le polling car vous évitez des appels JS->natif fréquents.

Quels pièges de performance sont courants avec le bridge classique ?

Trop de micro-appels au bridge, des payloads JSON volumineux et une sérialisation/désérialisation fréquente. Pour améliorer les performances : regrouper le travail, réduire la taille des payloads, éviter les appels haute fréquence et déplacer les calculs lourds vers JSI/TurboModules quand c’est approprié.

Quelle est la différence entre un module natif et un composant UI natif ?

Les modules natifs sont généralement invoqués de façon impérative depuis JS pour des actions ou des données. Les composants UI natifs sont rendus dans la hiérarchie des vues et supportent layout/props/événements de façon similaire aux composants React.

13Modules Turbo

Que sont les TurboModules dans la nouvelle architecture de React Native ?

Les TurboModules sont un mécanisme pour appeler des fonctionnalités natives depuis JS avec de meilleures performances grâce à JSI et à des bindings générés. Ils réduisent la surcharge par rapport au bridge classique sérialisé.

En quoi les TurboModules diffèrent-ils du bridge classique ?

Le bridge classique utilise généralement un passage de messages avec sérialisation et limite davantage l’accès synchrone. Les TurboModules utilisent des bindings directs via JSI, ce qui améliore les performances et permet du synchrone lorsque c’est sûr.

Que fait codegen pour les TurboModules ?

Codegen lit une spécification de module (types/spec) et génère les bindings JS/TS et la glue native pour que les deux côtés soient alignés sur les noms des méthodes et la forme des arguments, améliorant la sécurité de type et réduisant le boilerplate.

Quand une méthode TurboModule peut-elle être synchrone vs asynchrone ?

Le synchrone est utilisé pour les opérations rapides et suffisamment sûres pour s’exécuter immédiatement. L’asynchrone est utilisée pour l’IO, les traitements longs ou lorsque vous devez éviter de bloquer le thread JS.

Quels bénéfices principaux mentionner en entretien ?

De meilleures performances (moins de surcharge), un typage plus solide via specs/codegen, des contrats plus clairs entre JS et natif, et une meilleure intégration avec Fabric et le reste de la nouvelle architecture.

14Applications hors ligne

Quelles sont les stratégies courantes pour construire des apps React Native capables de fonctionner hors ligne ?

Utilisez une persistance locale (key-value ou base de données), mettez en cache les réponses GET, supportez une UI optimiste pour les écritures, mettez en file les mutations hors connexion, puis synchronisez à nouveau quand la connectivité revient.

Où stocker les données hors ligne sur mobile ?

Options fréquentes : AsyncStorage pour les petits couples clé/valeur, MMKV pour un cache key-value très rapide, et SQLite pour des données structurées/relationnelles et de plus grands jeux de données hors ligne.

Comment mettre en file les écritures et les rejouer plus tard ?

Stockez une file durable d’opérations en attente localement (avec timestamps et identifiants d’idempotence). Quand le réseau est disponible, rejouez les requêtes dans l’ordre et mettez à jour l’état local selon les réponses du serveur.

Comment résoudre les conflits lorsque l’appareil se reconnecte ?

Utilisez un versioning (ETags/updatedAt), choisissez une stratégie de conflit (last-write-wins, règles de fusion), et exposez les résolutions quand la fusion automatique n’est pas possible.

Comment détecter les changements de réseau dans React Native ?

Utilisez des bibliothèques comme @react-native-community/netinfo pour écouter les changements de connectivité et déclencher la synchronisation/le replay quand l’app regagne le réseau.

Quels patterns UX améliorent la fiabilité hors ligne ?

Affichez clairement le statut hors ligne, tenez l’utilisateur informé des actions en file, proposez des contrôles de retry quand la synchronisation échoue, et assurez la récupération après que l’app ait été tuée/redémarrée.

15Fonctions cloud

Qu’est-ce que sont les cloud functions et pourquoi les apps mobiles les utilisent ?

Les cloud functions (serverless) exécutent la logique backend sans que vous gériez des serveurs. Les clients mobiles les utilisent pour des opérations sécurisées : facturation, vérification des permissions, traitement de médias et agrégation de données.

Quels problèmes les cloud functions aident-ils à éviter ?

Elles aident à garder les secrets hors du client, à centraliser l’autorisation, à réduire la complexité côté client, et à permettre un traitement asynchrone (webhooks, tâches en background, synchronisation planifiée).

Comment concevoir des endpoints cloud pour les retries et l’idempotence ?

Supposez que les requêtes peuvent être répétées à cause de timeouts ou de retentatives du fournisseur. Utilisez des clés d’idempotence, assurez-vous que les opérations sont sûres à exécuter plusieurs fois, et renvoyez des résultats cohérents.

Comment gérer les webhooks de paiement avec des cloud functions ?

Créez un endpoint de webhook qui vérifie les signatures, mappe l’événement à vos enregistrements internes, met à jour l’état paiement/commande dans la base de données, et gère les événements dupliqués via l’idempotence.

Comment sécuriser des cloud functions ?

Utilisez l’authentification (JWT/Firebase auth), vérifiez les permissions/roles de l’appelant, validez les entrées et limitez l’accès avec des contrôles côté serveur et des variables d’environnement sécurisées.

16Rejets courants

Que signifie le fait qu’une Promise soit rejetée en JavaScript ?

Cela signifie que l’opération asynchrone a échoué. Le rejet porte une valeur d’erreur (souvent un objet Error). Si vous utilisez await, une exception est levée ; avec .then, vous devez gérer .catch.

Comment gérer les Promise rejetées avec async/await ?

Enveloppez les appels await dans un bloc try/catch, puis convertissez l’erreur capturée en message compréhensible et décidez s’il faut retenter ou mettre à jour l’UI.

Qu’est-ce qu’un unhandled promise rejection et pourquoi est-ce un problème ?

Un rejet non géré est une Promise rejetée sans handler catch. Cela peut faire planter l’application (ou échouer silencieusement selon l’environnement) et rend les erreurs plus difficiles à détecter et à corriger.

Comment différencier les erreurs réseau des erreurs HTTP ?

Les erreurs réseau indiquent généralement connectivité/timeout et peuvent ne pas avoir de statut HTTP. Les erreurs HTTP comportent un code de réponse (400/401/500, etc.). Classez selon la forme d’erreur renvoyée par votre client HTTP (Axios/fetch).

Comment implémenter des retries ?

Retentez uniquement les opérations idempotentes, utilisez un backoff exponentiel avec jitter, et retentez selon les catégories d’erreurs (par ex. 429/5xx ou erreurs réseau transitoires). Évitez les boucles de retry pour les erreurs de validation 4xx.

17Problèmes multiplateformes & approche de développement

Quels problèmes cross-plateforme avez-vous déjà vus entre iOS et Android ?

Différences de comportement du clavier, des flux de permissions, des chemins/restrictions liés aux fichiers et au stockage, du comportement des notifications, de la gestion des gestes, et de subtiles différences de layout/typographie selon la densité des appareils.

Quelle approche propre pour le code spécifique à la plateforme dans React Native ?

Utilisez Platform.OS pour de petites différences isolées, et gardez le code spécifique à la plateforme dans des modules/fichiers séparés quand c’est possible. Préférez la détection de capacités plutôt que des checks génériques du système.

Comment garder l’UI cohérente entre appareils et tailles d’écran ?

Utilisez des patterns de layout relatifs, évitez les hypothèses de pixels fixes, testez sur plusieurs tailles d’écran, et considérez les réglages d’accessibilité comme la mise à l’échelle dynamique des polices.

Comment déboguer un problème de layout qui n’apparaît que sur une seule plateforme ?

Reproduisez avec des logs spécifiques à la plateforme, inspectez le layout avec les RN dev tools, vérifiez le scaling des polices et la gestion de la safe area, puis contrôlez les différences de configuration native (barre d’état, notch, fuseau horaire, locale).

Quelle stratégie de test aide à repérer les régressions cross-plateforme ?

Combinez des tests unitaires pour la logique, des tests d’intégration/composants pour le comportement de l’UI et des tests end-to-end pour les parcours critiques sur iOS et Android. Ajoutez des vérifications visuelles/snapshots quand c’est approprié.

18Erreur API courante

Comment gérer HTTP 400 (Bad Request) dans une application mobile ?

Traitez cela comme une erreur de validation/entrée côté client. Analysez les erreurs au niveau des champs si elles sont disponibles, affichez des messages adaptés dans l’UI, et évitez de retenter tant que l’utilisateur n’a pas corrigé.

Comment gérer HTTP 401 (Unauthorized) et l’expiration du token ?

Déclenchez un flux de refresh token quand c’est possible, retentez la requête originale une seule fois après le refresh, et si le refresh échoue, redirigez vers login/logout et effacez les identifiants invalides.

Que signifient généralement 403, 404 et 409 ?

403 est lié aux permissions, 404 à une ressource/route manquante, et 409 à un conflit (souvent conflit de version/état). Associez chaque cas à une conséquence claire pour l’utilisateur et à la bonne action de récupération.

Que signifie HTTP 429 et comment réagir ?

Cela indique un rate limiting. Faites un backoff avec une logique retry-after exponentielle, réduisez la fréquence des requêtes et évitez de saturer l’API.

Comment gérer les erreurs serveur 5xx par rapport aux erreurs côté client ?

5xx est généralement transitoire. Retentez avec backoff pour les opérations sûres et affichez un message générique quand ce n’est pas récupérable. 4xx nécessite généralement l’action de l’utilisateur ou une correction de code.

Que faire quand l’erreur n’est pas une réponse HTTP (timeout, DNS, hors ligne) ?

Classez cela comme un échec réseau, affichez une option offline/retry, et envisagez de mettre en file des opérations pour synchroniser plus tard au lieu d’échouer immédiatement.

Sponsorisé

Promo rapide