React web ↔ React Native : les ponts

C'est la charnière du guide. Jusqu'ici on a construit les fondations du web comme si tu partais de zéro ; à partir de maintenant, tu ne pars plus de zéro du tout. Ce module fait l'inventaire honnête de ton bagage : ce qui se transfère tel quel (beaucoup), ce qui change de nom, ce qui change de comportement — c'est là que sont les pièges — et ce qui n'existe tout simplement pas de l'autre côté.

Le même React, deux cibles

Reprenons l'image du module Le modèle mental de React : React est une machine à fabriquer des écrans. Cette machine a deux moitiés très distinctes, et c'est cette séparation qui explique tout le module.

La première moitié, c'est le cœur (le paquet react) : composants, état, hooks, contexte, réconciliation, phases render et commit, flux unidirectionnel. Ce cœur ne sait absolument rien de ce à quoi il parle — ni les div, ni les UIView d'iOS. Il manipule des objets de description et calcule une liste d'ordres : « crée cet élément », « change cette propriété », « supprime celui-là », « déplace ce nœud ».

La seconde moitié, c'est le renderer (le « moteur de rendu »), l'organe qui exécute cette liste dans un monde concret. react-dom la traduit en manipulations du DOM du navigateur ; react-native, en instructions pour les vues natives iOS et Android. D'autres renderers existent, plus exotiques : un pour le terminal, un pour le PDF, un pour une scène 3D. Tous branchés sur le même cœur.

Conséquence directe : ce qui se transfère sans aucune modification couvre à peu près tout ce que tu écris dans une journée. Le JSX et ses règles (élément racine unique, fragments <>...</>, expressions entre accolades) ; les composants et les props, descendantes et en lecture seule, children compris ; l'état et sa règle d'or (« on ne mute jamais, on remplace ») ; tous les hooks et leurs règles d'appel ; le contexte contre le prop drilling ; tes hooks personnalisés, copiables tels quels tant qu'ils ne touchent que des données pures ; la réconciliation, les key, les causes d'un re-render. Tout ça vit dans le paquet react, donc à l'identique dans les deux mondes.

Ce qui change, en face, tient sur une ligne : les balises que tu écris dans le JSX, le nom de certaines props, et une poignée de comportements du navigateur. Le reste du module détaille cette petite liste — elle est petite précisément parce que l'inventaire ci-dessus est grand.

// A — hooks/useDebounce.ts
export function useDebounce(value, delay) {
  const [debounced, setDebounced] = useState(value);
  useEffect(() => {
    const id = setTimeout(() => setDebounced(value), delay);
    return () => clearTimeout(id);
  }, [value, delay]);
  return debounced;
}

// B — components/Badge.tsx
export function Badge({ label }) {
  return <View style={styles.badge}><Text>{label}</Text></View>;
}

// C — lib/formatDuration.ts
export const formatDuration = (min) => `${min} min`;

La table de traduction des primitives

Voici le cœur pratique du module : la table de correspondance, dans le sens mobile → web cette fois. Tu as appris l'aller dans « React Native : les briques natives » ; voici le retour. Lis la troisième colonne attentivement — c'est là que vivent les nuances qui font qu'une traduction naïve produit un résultat bancal.

Trois lignes de ce tableau méritent qu'on s'y attarde, parce qu'elles ne sont pas de simples renommages.

Le texte, d'abord. La règle non négociable de React Native — « tout texte vit dans un <Text>, sinon l'app plante » — n'a aucun équivalent sur le web : <div>Bonjour</div> est parfaitement légal. La raison est généalogique. Le HTML est né comme un format de documents texte, où le texte est citoyen de première classe et les balises de simples annotations autour de lui ; les systèmes natifs sont nés comme des systèmes de vues, où afficher du texte demande un objet particulier (un UILabel). Conséquence pratique : cette liberté ne veut pas dire que tout se vaut. Un <p> pour un paragraphe, un <h2> pour un titre — pas pour éviter un crash, mais pour le sens, l'accessibilité et le SEO. Le web te fait confiance ; à toi de mériter cette confiance.

Le défilement, ensuite. En RN, un écran trop long est simplement coupé, et c'est le ScrollView qui rend le défilement. Sur le web, c'est l'inverse : le document défile par défaut, et ce depuis 1993 — le « composant qui rend ma page défilable » n'existe pas. La question web est symétrique : « ai-je besoin d'une zone qui défile indépendamment du reste ? ». Si oui, overflow-y: auto et une hauteur sur cette boîte-là. Sinon, tu ne fais rien.

Les listes, enfin. Sur mobile, la virtualisation — ne rendre que les éléments visibles et recycler leurs vues au défilement — est presque un réflexe : 800 exercices dans un ScrollView, et l'app rame. Le navigateur, lui, encaisse des milliers de nœuds DOM sans broncher : écris un .map() tout bête, et ne virtualise que si tu as mesuré un problème. Les bibliothèques existent (TanStack Virtual, react-window) mais elles coûtent cher — hauteurs à connaître, accessibilité à surveiller, Ctrl+F qui ne trouve plus le texte hors écran.

Les événements : là où ça trébuche vraiment

On arrive au piège numéro un du passage mobile → web, celui qui fait perdre vingt minutes à tout le monde au moins une fois. Le renommage onPress → onClick est trivial : ton éditeur t'engueule si tu te trompes. Le vrai piège est ailleurs, et il est silencieux.

En React Native, onChangeText te donne directement la chaîne saisie — une commodité de l'équipe React Native, d'où l'écriture minimaliste onChangeText={setEmail}. Sur le web, onChange te donne un objet événement : quel élément a été touché, quel type d'événement, à quel moment, quelles touches modificatrices étaient enfoncées. La valeur du champ est cachée dedans, dans event.target.value — target, « la cible », étant l'élément du DOM sur lequel l'événement s'est produit.

// ─────────── React Native ───────────
// onChangeText reçoit DIRECTEMENT la chaîne saisie.
<TextInput value={fullName} onChangeText={setFullName} />

// ─────────── React web ───────────
// onChange reçoit un ÉVÉNEMENT ; la valeur est dedans.
<input value={fullName} onChange={(e) => setFullName(e.target.value)} />

// ⛔ Le piège : ceci « marche » sans erreur, mais range
//    l'objet événement entier dans l'état au lieu du texte.
<input value={fullName} onChange={setFullName} />

La dernière ligne est le réflexe mobile mal transposé. TypeScript t'en protège souvent, mais en JavaScript pur elle passe sans un mot : ton état contient un objet, ton champ affiche [object Object] ou reste vide, et tu cherches pendant vingt minutes.

Sous toutes ces écritures, le patron ne change pas : c'est Le nom d'événement et son callback, isolé au module Le navigateur : DOM, événements, rendu. En vanilla JS tu écrivais element.addEventListener('input', callback) ; ici tu écris onChange={callback}. React pose l'écouteur à ta place et enveloppe l'événement, mais le couple — un nom d'événement, une fonction à rappeler — n'a pas bougé d'un millimètre. Ce qui a bougé, et c'est tout le piège ci-dessus, c'est ce que ce callback reçoit en argument.

Les événements synthétiques, expliqués simplement

Le e que tu reçois n'est pas l'événement natif du navigateur : c'est un SyntheticEvent, une enveloppe que React met autour, avec la même interface (target, preventDefault(), stopPropagation()…). Pourquoi ? Raison historique : les navigateurs ont longtemps eu des implémentations divergentes, et l'enveloppe les normalise. Raison architecturale : React n'attache pas un écouteur par bouton, il en attache quelques-uns à la racine et se sert de la propagation — la remontée des événements dans l'arbre du DOM, détaillée dans « Le navigateur : DOM, événements, rendu ». Une page avec mille boutons a une poignée d'écouteurs, pas mille.

La conséquence pratique la plus visible, c'est preventDefault(). Certains éléments HTML ont un comportement par défaut câblé dans le navigateur : un <form> soumis recharge la page, un <a> cliqué navigue, une case à cocher se coche. e.preventDefault() dit « n'applique pas ce comportement par défaut, je m'en occupe ». Sur mobile, cette notion n'existe carrément pas — aucune primitive React Native n'a de comportement par défaut à annuler. C'est du pur web, et tu vas l'écrire des centaines de fois.

<form onSubmit={(e) => {
  // Sans ceci, le navigateur RECHARGE la page et ton React
  // est réinitialisé : état perdu, requête jamais partie.
  e.preventDefault();
  submitRequest({ fullName, email, service });
}}>
  <label htmlFor="nom">Nom complet</label>
  <input
    id="nom"
    value={fullName}
    onChange={(e) => setFullName(e.target.value)}
  />

  {/* type="submit" : c'est LUI qui déclenche onSubmit du form. */}
  <button type="submit">Confirmer le rendez-vous</button>
</form>

// ─────────── L'ORIGINAL (React Native) ───────────
function NoteField({ note, setNote }) {
  return (
    <View style={styles.field}>
      <Text>Note de séance</Text>
      <TextInput value={note} onChangeText={setNote} />
    </View>
  );
}

// ─────────── LA TRADUCTION (React web) ───────────
function NoteField({ note, setNote }) {
  return (
    <div class="field">
      <Text>Note de séance</Text>
      <input value={note} onChangeText={setNote} />
    </div>
  );
}

const [fullName, setFullName] = useState('');

// Traduit d'un <TextInput value={fullName} onChangeText={setFullName} />
<input value={fullName} onChange={setFullName} />

Le style : de StyleSheet aux classes CSS

Tes deux façons de styler sur mobile — les objets de StyleSheet.create et les classes NativeWind — existent toutes deux sur le web, mais l'équilibre s'inverse. La voie principale du web, c'est la classe CSS. Ce n'est pas une question de goût : elle seule donne accès aux media queries, aux pseudo-classes (:hover, :focus, :disabled), aux animations, aux variables CSS et à la cascade. Un objet de style en ligne ne sait exprimer qu'un état statique.

Le style en ligne existe aussi, sous la forme que tu connais : la prop style prend un objet JavaScript en camelCase. Une seule vraie différence, les unités — un nombre nu est interprété en pixels ({{ marginTop: 16 }} devient margin-top: 16px) et toute autre unité s'écrit en chaîne ({{ width: '50%' }}, {{ fontSize: '1.25rem' }}), là où les nombres de RN sont des unités indépendantes de la densité de l'écran.

// Style EN LIGNE (web) : objet camelCase.
// Nombre nu = pixels ; toute autre unité = chaîne de caractères.
<div style={{ marginTop: 16, width: '50%', fontSize: '1.25rem' }} />

// Style par CLASSE : la voie normale du web.
<div className="carte carte--active" />

// Classes conditionnelles : c'est juste du JavaScript qui
// fabrique une chaîne — même astuce que sur mobile.
<button className={`btn ${isActive ? 'btn--actif' : ''}`} />

Le style en ligne est réservé aux valeurs calculées (une largeur de barre de progression, une couleur venue de données). Tout le reste passe par des classes : elles seules donnent accès à :hover, aux media queries et à la cascade.

Et Tailwind ? NativeWind est Tailwind porté à React Native : mêmes noms de classes, même échelle d'espacement, même modèle mental. Ton bagage se transfère presque intégralement. Ce que tu gagnes en plus, ce sont les préfixes d'état et de largeur qui n'avaient aucun sens sur un téléphone : hover:bg-blue-600, focus:ring-2, md:flex-row, dark:bg-slate-900. Chacun correspond à une pseudo-classe ou une media query du module « CSS 2 — grid, responsive, variables ». Tu ne réapprends pas Tailwind : tu débloques la moitié qui dormait.

<div className="jauge">
  <div style={{ width: 50, height: 8, backgroundColor: 'teal' }} />
</div>

Ce qui n'existe que d'un côté

Jusqu'ici on a traduit. Cette section-ci parle de ce qui n'a pas de traduction, dans les deux sens. C'est souvent là que les entrevues creusent : ça révèle si tu as compris la plateforme ou seulement mémorisé un tableau.

Ce qui n'existe que sur le web

Le HTML sémantique. En RN, tout est View ; le sens vit dans le nom de tes composants et dans ta tête. Sur le web, la balise elle-même porte le sens, et le navigateur en tire des conséquences réelles : navigation par titres pour les lecteurs d'écran, régions repérables, comportements clavier gratuits (« HTML sémantique & accessibilité »).

L'URL, et c'est énorme. Sur mobile, la navigation est une pile d'écrans qui vit dans la mémoire de l'app et meurt avec elle. Sur le web, chaque état de l'interface qui mérite d'exister a une adresse : elle se copie, se colle dans un message, se met en favori, s'indexe par Google, revit intacte demain sur un autre ordinateur. C'est un état partageable et persistant — la caractéristique la plus profonde du web.

Le clavier et le focus. Sur le web, il y a en permanence un élément qui a le focus, l'utilisateur le déplace avec Tab, et tout un pan de l'accessibilité tient à ce que ce parcours soit logique et visible — un réflexe entièrement neuf pour toi. Le survol : :hover n'a aucun sens sur un écran tactile, mais c'est sur le web un signal d'affordance central (« ceci est cliquable »). Comme un navigateur tourne aussi sur téléphone, la règle est : le survol enrichit, il ne doit jamais être le seul accès à une information.

L'onglet, le SEO, le partage. Ta page a un titre d'onglet, une description que Google lira, une image d'aperçu quand on la partage ; une app mobile a une icône sur un écran d'accueil, et c'est tout. Conséquence architecturale majeure : c'est en grande partie pour le SEO et la vitesse de premier affichage que Next.js a inventé le rendu côté serveur, sujet des modules « La carte de Next.js » et « Server et Client Components ».

Ce qui n'existe que sur mobile

• Les permissions natives — caméra, micro, contacts, notifications push, localisation en arrière-plan, santé. Le web a des équivalents partiels, bien plus restreints, systématiquement soumis à une action explicite de l'utilisateur.
• Le cycle de vie de l'application — l'AppState d'Halterofit n'a pas d'équivalent direct. Le web a des cousins (visibilitychange, le focus de la fenêtre), mais un onglet peut être suspendu, fermé d'un coup ou dupliqué, sans cérémonie.
• Les gestes natifs et les animations hors du fil JavaScript — Reanimated et les gestionnaires de gestes ne se transposent pas : le web a d'excellents outils d'animation, mais pas le même modèle d'exécution.
• Le stockage local franc — MMKV, SQLite via WatermelonDB, un système de fichiers : ton app possède réellement de l'espace sur l'appareil. Le web a localStorage (petit, synchrone, texte) et IndexedDB (puissant mais verbeux), dans un bac à sable que l'utilisateur vide d'un clic.

Le point d'entrée d'une app React web

Voici une question d'entrevue junior à laquelle beaucoup de gens qui « font du React » ne savent pas répondre, parce que leur outillage la leur a toujours cachée : comment une application React démarre-t-elle, concrètement ? Tout commence par un fichier HTML d'une pauvreté remarquable. Le navigateur ne sait faire qu'une chose — télécharger un document et le transformer en DOM — et n'a jamais entendu parler de React : il lui faut donc un document, et ce document contient essentiellement une boîte vide et un script.

<!DOCTYPE html>
<html lang="fr">
  <head><title>Clinique RendezVous</title></head>
  <body>
    <!-- La boîte vide. TOUTE l'app vivra là-dedans. -->
    <div id="root"></div>

    <!-- Le script qui va la remplir. -->
    <script type="module" src="/src/main.tsx"></script>
  </body>
</html>

Ouvre le code source d'une application React classique dans ton navigateur : tu verras littéralement ça. Une page vide et un script. Tout le reste est fabriqué en JavaScript, après coup — d'où le nom de SPA, « Single Page Application ».

Le script, lui, tient en deux lignes utiles. Il trouve la boîte vide dans le DOM, crée une racine React attachée à cette boîte, et lui demande d'y peindre ton composant principal.

import { createRoot } from 'react-dom/client';
import App from './App';

// 1. On trouve la boîte vide définie dans index.html
// 2. createRoot en fait un « territoire » géré par React
// 3. render y peint l'arbre décrit par <App />
createRoot(document.getElementById('root')).render(<App />);

Compare avec le mobile : dans une app Expo, tu n'as jamais écrit ces lignes — tu as registerRootComponent(App), souvent caché par Expo Router. Le rôle est rigoureusement le même : désigner le sommet de l'arbre et le brancher sur une surface d'affichage. Seule la surface change. Le vocabulaire aussi appartient à React et pas à une plateforme : monter (le premier rendu, celui qui crée les nœuds), démonter (la disparition, celle qui déclenche le nettoyage des useEffect). Dernier détail : ReactDOM.render(...) sans createRoot, croisé dans un vieux tutoriel, c'est l'API d'avant React 18, dépréciée.

<!-- index.html -->
<body>
  <div id="app"></div>
  <script type="module" src="/src/main.tsx"></script>
</body>

// src/main.tsx
createRoot(document.getElementById('root')).render(<App />);

Les listes et les clés

Sur mobile, une liste passe par FlatList ou FlashList, avec ses props data et renderItem. Sur le web, la mécanique est plus nue : tu écris toi-même le .map() qui transforme un tableau de données en tableau d'éléments JSX, et React sait afficher un tableau d'éléments.

const services = [
  { id: 'gen',    name: 'Consultation générale', duration: 20 },
  { id: 'physio', name: 'Physiothérapie',         duration: 45 },
  { id: 'vacc',   name: 'Vaccination',             duration: 15 },
];

// Une liste sémantique (ul/li), pas un empilement de div.
<ul className="services">
  {services.map((s) => (
    <li key={s.id}>
      <h3>{s.name}</h3>
      <p>{s.duration} minutes</p>
      <button type="button" onClick={() => selectService(s.id)}>Choisir</button>
    </li>
  ))}
</ul>

La key et la réconciliation, tu les connais depuis « Le modèle mental de React » : une identité stable permet à React de déplacer un nœud existant au lieu de le détruire et d'en recréer un autre. Ce que le web ajoute, c'est l'enjeu. Un nœud du DOM transporte de l'état invisible, que React ne possède pas et ne sait pas reconstruire : le texte tapé dans un <input> non contrôlé — un champ dont la valeur vit dans le DOM et non dans un état React, notion démontée dans « Formulaires 1 — contrôlé ou non » —, la position du curseur, l'élément qui a le focus, la case cochée, la position de défilement, une animation en cours. Sur mobile, cette réserve d'état hors-React est minuscule ; sur le web, elle est partout. D'où le renversement : une mauvaise key ne « ralentit » pas, elle fait sauter des données d'une ligne à l'autre. L'exercice qui suit en est le cas d'école.

{sortedRequests.map((request, index) => (
  <li key={index}>
    <input type="checkbox" />   {/* case NON contrôlée */}
    <span>{request.name} — {request.service}</span>
  </li>
))}

Le rendu conditionnel, et le piège du zéro

Les trois techniques — le && pour « affiche seulement si », le ternaire ? : pour « ceci ou cela », l'early return pour les cas d'exception franche — sont identiques des deux côtés, tu les emploies déjà. Une seule chose est à graver, parce que tout le piège qui suit en découle : React n'affiche rien pour null, undefined, true et false — et rien d'autre n'est ignoré.

{freeSlots.length && <p>{freeSlots.length} créneaux libres</p>}

// A
{slots.length && <p>Prochaine disponibilité : {slots[0].time}</p>}

// B
{selectedService && <p>Service : {selectedService.name}</p>}

// C
{message.length && <p className="erreur">{message}</p>}

function ServiceRow({ name, waitMinutes }) {
  return (
    <li>
      {name}
      {waitMinutes && <span> — {waitMinutes} min d'attente</span>}
    </li>
  );
}

Ce que tu dois désapprendre

On a beaucoup parlé de ce qui se transfère. Terminons par la courte liste de ce qui, au contraire, va te trahir — des automatismes tellement ancrés que tu les appliqueras sans même y penser.

1. Les nombres nus ne sont pas les mêmes unités. En RN, width: 200 exprime 200 points indépendants de la densité. Sur le web, 200 veut dire 200 pixels CSS, une unité fixe qui ne s'adapte à rien — ni à la fenêtre, ni aux préférences de taille de police de l'utilisateur. D'où rem (relatif à la police racine, donc respectueux des réglages d'accessibilité), %, vw / vh, ch, et clamp(). Le réflexe : sur le web, tout en pixels fixes est un choix, pas un défaut (module « CSS 2 — grid, responsive, variables »).

2. Rien n'est en flex, et flex est en ligne. Un div est display: block, et un conteneur flex empile en ligne par défaut. Colonne = flex-direction: column, explicite, toujours. 3. Le texte n'a pas besoin d'être enveloppé. Ta discipline mobile va te faire chercher un composant Text qui n'existe pas : écris le texte, et choisis la balise pour son sens (p, h2, label, strong).

4. Le CSS cascade, et ça change tout. C'est la différence de fond, celle qui va au-delà des noms. En React Native, les styles sont isolés : un style ne s'applique qu'à son composant et personne ne peut l'écraser à distance. Sur le web, le CSS est global, à cascade et à héritage : une règle s'applique à tout ce qui correspond à son sélecteur, certaines propriétés descendent aux enfants (color, font-family…), et la spécificité tranche les conflits. Une classe écrite par un collègue à l'autre bout du projet peut donc légalement changer l'apparence de ton composant. Ce n'est pas un défaut, c'est le modèle — et c'est exactement le problème que résolvent les CSS Modules, les composants stylés et Tailwind : recréer de l'isolation dans un système global par nature.

5. Le clavier et le focus existent. Une modale qui ne rend pas le focus au bouton qui l'a ouverte, un menu qu'on ne ferme pas avec Échap, un contour de focus supprimé « parce que c'est moche » : des défauts réels, d'une catégorie neuve pour toi. 6. Le premier rendu compte. Sur mobile, le code est déjà installé ; sur le web, chaque visiteur télécharge ton JavaScript avant de voir quoi que ce soit. Poids du paquet et temps avant premier affichage sont des préoccupations quotidiennes — et la raison d'être d'une bonne partie de Next.js.