React Native : les briques natives

Tu connais déjà React (« Le modèle mental de React », « useState & useEffect »). Bonne nouvelle : React Native, c'est exactement le même cerveau — composants, props, JSX, hooks — mais au lieu de dessiner du HTML dans un navigateur, ton code pilote de vraies vues natives iOS et Android. Ce module t'apprend à reconnaître les nouvelles briques (qui remplacent div, span, button) pour que le code de Halterofit cesse de te sembler étranger.

1. Ce qu'est React Native (et ce qu'il n'est pas)

Quand tu fais du React « web », ton code finit par produire du HTML (des <div>, des <p>) que le navigateur affiche en manipulant le DOM — l'arbre des éléments de la page. React, là, est un chef d'orchestre : il décide quoi afficher, et un « moteur de rendu » (ReactDOM) traduit ses décisions en HTML réel.

React Native garde exactement le même chef d'orchestre — le cœur de React, celui qui gère l'état, les props, le re-render dont on a parlé dans « Le modèle mental de React » — mais change le moteur de rendu. Au lieu de produire du HTML pour un navigateur, il produit des instructions pour les composants natifs d'iOS (UIView, UILabel…) et d'Android (View, TextView…). Le résultat : pas de page web, pas de DOM, pas de navigateur — une vraie app installable, avec les vraies animations natives, le vrai clavier natif, la vraie barre de défilement native.

2. React (web) vs React Native : oublie div, span, p, button

Le réflexe le plus dur à perdre, quand on vient du web, c'est de taper <div>. En React Native, ces balises HTML n'existent pas. Il faut les remplacer par des composants importés depuis 'react-native'. Voici la table de traduction mentale à garder sous la main :

Tu remarques un détail de nommage : en HTML les balises sont en minuscules (div) ; en React Native elles commencent par une majuscule (View). Ce n'est pas un caprice : en JSX, une balise minuscule signifie « élément natif intégré », une balise majuscule signifie « composant React que j'ai importé ». Comme View est un composant importé de 'react-native', il prend la majuscule. C'est la même règle que pour tes propres composants comme <Button> ou <ScreenContainer>.

3. Les primitives de base, une par une

« Primitive » est le mot consacré pour les briques fournies de base par React Native, celles dont tout le reste est construit. Prenons-les une à une, avec la théorie d'abord.

View — la boîte universelle

View est l'équivalent direct du <div> : une boîte invisible qui sert à regrouper et à positionner d'autres éléments. Elle ne montre rien elle-même (pas de texte, pas d'image) ; son rôle est structurel. La grande différence avec le web : une View est en Flexbox par défaut (on y revient en §4), ce qui veut dire qu'elle sait nativement empiler et aligner ses enfants. Tu vas en voir partout : c'est l'ossature de chaque écran. Dans Halterofit, l'écran d'inscription est une View qui contient une autre View (la pile de champs), qui contient les champs.

Text — TOUT texte vit dans un Text

Règle stricte et non négociable de React Native : tout texte affiché à l'écran doit être enveloppé dans un <Text>. Sur le web tu peux écrire du texte directement dans un <div> ; ici, c'est interdit. Pourquoi ? Parce que les systèmes natifs traitent le texte comme un type d'élément à part (un UILabel sur iOS) : impossible de coller des caractères dans un conteneur générique. Si tu mets du texte « nu » dans une View, l'app plante (on en reparle dans « Piège fréquent »). Autre conséquence agréable : les Text peuvent s'imbriquer pour styler un bout de phrase — tu verras dans Halterofit un Text de paragraphe contenir des Text colorés pour les liens « Terms of Service » et « Sign in ».

Pressable — la zone tactile

Sur mobile, on ne « clique » pas, on touche. Pressable est la primitive moderne pour « rendre quelque chose tactile ». Tu enveloppes n'importe quoi (un Text, une icône, une View entière) dans un Pressable, et tu lui passes un onPress — l'exact équivalent du onClick du web. Tout le reste de ton modèle d'événements React reste identique : onPress reçoit une fonction, qui s'exécute au toucher. Halterofit s'en sert par exemple pour le petit bouton « œil » qui montre/cache le mot de passe, et pour le lien « Already have an account? Sign in ».

ScrollView vs FlatList / FlashList — et pourquoi la virtualisation

Un écran ne tient pas toujours dans la hauteur du téléphone : il faut pouvoir faire défiler. ScrollView est la solution simple : tu mets ton contenu dedans, ça devient défilable. Mais ScrollView a un défaut grave pour les longues listes : il rend TOUS ses enfants d'un coup, même ceux qu'on ne voit pas. Imagine une base de 800 exercices : ScrollView construirait 800 lignes en mémoire dès le départ. C'est lent à ouvrir et ça mange la RAM.

La solution est la virtualisation : ne construire en mémoire que les éléments actuellement visibles (plus un petit coussin au-dessus et en dessous), et recycler ces « cases » au fur et à mesure que tu défiles. L'utilisateur a l'impression d'une liste de 800 éléments, mais à tout instant seulement une douzaine existent vraiment. C'est le métier de FlatList (la version intégrée à React Native) et de FlashList (une version encore plus rapide, signée Shopify). Halterofit utilise FlashList pour ses longues listes — typiquement la liste d'exercices et l'historique. À toi : longue liste qui défile à l'infini → liste virtualisée ; petit contenu fixe → ScrollView suffit.

TextInput — le champ de saisie « contrôlé »

TextInput est le champ de saisie. Le point théorique important, c'est le patron du composant contrôlé, déjà rencontré avec useState. L'idée : le champ ne garde pas sa propre valeur dans son coin ; c'est ton état React qui est la source de vérité. Tu branches deux fils :

• value : ce que le champ affiche, lu depuis ton état (ex. value={email}).
• onChangeText : appelé à chaque frappe, avec le nouveau texte, pour mettre ton état à jour (ex. onChangeText={setEmail}).

Note la différence avec le web : là-bas l'événement s'appelle onChange et te donne un objet-événement (e.target.value). Ici c'est onChangeText et il te donne directement la chaîne — plus simple. La boucle est : l'utilisateur tape → onChangeText met à jour l'état → l'état redonne value au champ → l'écran se redessine. Le champ et l'état restent toujours synchronisés.

Image / expo-image, et ActivityIndicator

Image affiche une image. Tu lui passes une source (le fichier ou l'URL) et un style avec la taille. Halterofit affiche son logo-mot (« wordmark ») ainsi. Dans une vraie app on préfère souvent expo-image, une version améliorée fournie par Expo : meilleure mise en cache, fondu d'apparition, performance accrue — utile pour des images distantes (photos d'exercices, avatars). Quand tu vois un import depuis 'expo-image', lis-le comme « Image, en mieux ».

ActivityIndicator, enfin, est le petit spinner natif « ça charge ». Tu l'affiches pendant une opération asynchrone (une requête réseau) et tu le caches quand c'est fini. Halterofit le montre dans le bouton « Create Account » pendant l'inscription : tant que ça travaille, le bouton affiche la roue ; sinon il affiche son texte.

4. Le style en React Native : pas de fichier CSS

Gros choc culturel pour qui vient du web : il n'y a pas de fichiers .css. On ne sépare pas « le HTML d'un côté, le CSS de l'autre ». Le style se déclare en JavaScript, sous deux formes que tu croiseras toutes les deux dans Halterofit.

Forme A — l'objet de style avec StyleSheet.create. Tu décris le style comme un objet JavaScript (les propriétés ressemblent au CSS mais en camelCase : backgroundColor au lieu de background-color), et tu le passes via la prop style. StyleSheet.create regroupe ces objets proprement. Voici le pied de page de l'app, la barre d'onglets, écrit ainsi :

// Les styles sont des OBJETS JS, pas du CSS. Propriétés en camelCase.
const styles = StyleSheet.create({
  tabBar: {
    backgroundColor: Colors.background.surface,
    borderTopWidth: 1,                 // équivaut à border-top-width: 1
    borderTopColor: Colors.background.elevated,
    height: TAB_BAR_HEIGHT,
    paddingBottom: TAB_BAR_PADDING_BOTTOM,
    paddingTop: TAB_BAR_PADDING_TOP,
  },
  tabLabel: {
    fontSize: FONT_SIZE_LABEL,
    fontWeight: FONT_WEIGHT_SEMIBOLD,
  },
});

// On l'applique ensuite via la prop `style` : tabBarStyle: styles.tabBar

Remarque la View racine de ce fichier : style={{ flex: 1, backgroundColor: ... }} — un style « en ligne » écrit directement dans la balise. flex: 1 veut dire « occupe tout l'espace disponible », un grand classique du Flexbox.

Forme B — NativeWind (les classes Tailwind via className). Plutôt que des objets style, Halterofit utilise surtout NativeWind : tu écris des classes utilitaires Tailwind dans une prop className ("flex-1 items-center px-6"), et NativeWind les traduit en style natif. C'est la même philosophie que Tailwind sur le web, portée au mobile. Tu verras donc, côte à côte, des composants stylés par className (la majorité) et quelques-uns par style (quand on a besoin de valeurs calculées, comme une marge dépendant des encoches de l'écran).

5. Sous le capot : deux mondes qui se parlent

Tu n'as pas besoin de ça pour lire le code au quotidien, mais comprendre l'architecture éclaire beaucoup de « pourquoi ». Une app React Native vit dans deux mondes en parallèle :

• Le côté JavaScript : un moteur (Hermes, chez Expo) qui exécute ton code — tes composants, ton état, ta logique. C'est là que React « pense ».
• Le côté natif : le vrai iOS / Android, qui dessine les vues à l'écran, gère le toucher, la caméra, le stockage, etc.

Quand ton code JS dit « affiche cette View avec ce texte », ce message doit traverser jusqu'au côté natif qui, lui, dessine vraiment. Historiquement ce passage se faisait par un « pont » (le bridge) qui sérialisait les messages ; la nouvelle architecture de React Native rend ce dialogue beaucoup plus direct et rapide. Tu n'as pas à connaître les détails, mais retiens l'image : ton JS décide, le natif exécute, et il y a une frontière entre les deux.

6. Les différences de plateforme : iOS vs Android

Une même app tourne sur deux systèmes qui ne se comportent pas toujours pareil. React Native te donne un outil simple pour t'adapter : l'objet Platform.

• Platform.OS est une chaîne : 'ios', 'android' (ou 'web'). Tu peux donc écrire des conditions if dessus.
• Platform.select({ ... }) choisit une valeur selon la plateforme — pratique pour donner une valeur différente par OS sans empiler les if.

Dans l'écran d'inscription de Halterofit, on s'en sert pour le clavier. Sur iOS, on veut que la vue remonte ('padding') quand le clavier apparaît, pour ne pas masquer le champ ; sur Android, le système gère ça autrement, donc on ne force rien (undefined) :

<KeyboardAvoidingView
  // Sur iOS on pousse le contenu vers le haut ; sur Android, comportement par défaut.
  behavior={Platform.OS === 'ios' ? 'padding' : undefined}
  className="flex-1"
>

KeyboardAvoidingView est la View spéciale « ne te laisse pas cacher par le clavier ». Le Platform.OS === 'ios' ? ... : ... est un simple ternaire JavaScript : « si on est sur iOS, alors 'padding', sinon undefined ».

7. Mise en pratique : décortiquer sign-up.tsx

Mettons tout ensemble sur un vrai morceau de l'écran d'inscription. Voici son cœur, légèrement raccourci. Lis-le en repérant chaque primitive ; les commentaires pointent les briques.

return (
  <ScreenContainer>
    {/* View spéciale : empêche le clavier de cacher les champs. */}
    <KeyboardAvoidingView
      behavior={Platform.OS === 'ios' ? 'padding' : undefined}
      className="flex-1"
    >
      {/* View = la boîte. Flexbox : centré, du padding (style NativeWind). */}
      <View className="flex-1 items-center pt-52 px-6">
        {/* Image = le logo-mot. source + style (taille en objet JS). */}
        <Image source={WORDMARK} style={{ width: 240, height: 40 }} resizeMode="contain" />

        {/* La pile de champs : une View qui empile (colonne) avec un écart (gap-4). */}
        <View className="w-full max-w-sm gap-4">
          {/* TextInput contrôlé : value lue de l'état, onChangeText le met à jour. */}
          <Input
            placeholder="Email"
            value={email}
            onChangeText={setEmail}
            editable={!isLoading}      {/* champ gelé pendant le chargement */}
          />

          {/* Affichage conditionnel : on ne montre le Text d'erreur que s'il y en a une. */}
          {error !== '' && <Text className="text-destructive">{error}</Text>}

          {/* Pressable (via Button) : onPress remplace onClick. */}
          <Button onPress={handleSignUp} disabled={isLoading} size="lg">
            {isLoading
              ? <ActivityIndicator color={Colors.primary.foreground} />  /* ça charge */
              : <Text>Create Account</Text>}                          {/* sinon le libellé */}
          </Button>
        </View>
      </View>
    </KeyboardAvoidingView>
  </ScreenContainer>
);

Note que Input et Button sont des composants maison de Halterofit (majuscule), bâtis par-dessus TextInput et Pressable pour porter le style de l'app. Sous le capot, ce sont bien les primitives natives.

Relis ce bloc et tu retrouves toute la grammaire React que tu connais déjà : le JSX, les props (value, onPress), l'affichage conditionnel avec && et le ternaire ? : (vu dans « Le modèle mental de React »), l'état via useState (email, isLoading… vus dans « useState & useEffect »). Le seul changement, encore une fois, c'est le nom des balises. C'est ça, la bonne nouvelle de React Native.

{isLoading ? (
  <ActivityIndicator color={Colors.primary.foreground} />
) : (
  <Text>Create Account</Text>
)}