useContext, useMemo, useCallback, memo

Voici les quatre outils qui font peur sur le papier et qui, une fois compris, deviennent presque évidents. Ils ne sont pas là pour rendre ta vie compliquée : ils répondent tous à des problèmes très précis du modèle « ma fonction-composant est rappelée en boucle » qu'on a posé dans le module sur le modèle mental de React. La règle du jeu aujourd'hui : on prend le temps de comprendre le pourquoi profond avant le comment. Une fois le problème vraiment vu, le hook se lit tout seul.

1. L'égalité référentielle — la vérité cachée derrière tout

Avant même de parler de React, il faut comprendre une bizarrerie de JavaScript qui est, à elle seule, la clé de tout ce module. Si tu retiens une seule section aujourd'hui, c'est celle-ci. Quand tu auras compris pourquoi {} !== {}, la moitié de React qui te paraissait magique deviendra logique.

En JavaScript, il existe deux familles de valeurs, et elles ne se comparent pas du tout de la même façon. D'un côté, les valeurs primitives : nombres, chaînes, booléens. De l'autre, les objets : les objets au sens large, donc aussi les tableaux et les fonctions (oui, une fonction est un objet en JavaScript).

Les primitives se comparent par leur contenu. C'est intuitif :

// Deux primitives identiques SONT égales. Logique, rassurant.
2 === 2            // true
'rouge' === 'rouge' // true
true === true       // true

Les objets, eux, se comparent par leur identité — autrement dit par leur référence, leur « adresse en mémoire ». Deux objets qui ont exactement le même contenu mais qui ont été créés séparément sont considérés comme différents. C'est ici que ça devient déroutant la première fois :

// Même contenu visible... et pourtant DIFFÉRENTS.
{} === {}              // false  ← deux objets vides, mais créés séparément
[] === []              // false  ← deux tableaux vides, idem
[1, 2] === [1, 2]      // false  ← même contenu, références différentes
(() => {}) === (() => {}) // false  ← deux fonctions identiques au code près

// La SEULE façon d'avoir true : que ce soit le MÊME objet.
const a = { couleur: 'rouge' };
const b = a;           // b pointe vers le même objet que a
a === b                // true   ← même référence, pas une copie

« D'accord, mais en quoi ça concerne React ? » Énormément. Souviens-toi du module sur le modèle mental de React : à chaque rendu, la fonction-composant re-tourne en entier. Donc chaque ligne qui écrit un objet, un tableau ou une fonction crée une toute nouvelle référence à chaque rendu :

function Ecran() {
  // À CHAQUE rendu, ces trois lignes fabriquent des objets/fonctions NEUFS.
  const style = { padding: 16 };          // nouvel objet à chaque rendu
  const ids = [1, 2, 3];                   // nouveau tableau à chaque rendu
  const onPress = () => console.log('go'); // nouvelle fonction à chaque rendu

  // style, ids, onPress sont "les mêmes pour toi"... mais pour === ils sont
  // DIFFÉRENTS d'un rendu à l'autre. C'est exactement ce qui "casse" memo.
  return /* ... */;
}

Retiens cette phrase comme un mantra : « même contenu » n'est pas « même référence ». React, quand il compare des props ou des dépendances, regarde la référence, pas le contenu. Tout le reste du module — pourquoi memo ne marche pas tout seul, pourquoi useMemo et useCallback existent, pourquoi les tableaux de dépendances comptent — découle directement de ce seul fait. On va y revenir sans cesse.

2. Le vrai coût d'un re-render — c'est cher quand ?

Avant de dégainer la moindre optimisation, il faut une intuition juste de ce qui coûte cher et de ce qui ne coûte rien. Beaucoup de débutants « optimisent » des choses gratuites et alourdissent leur code pour zéro gain. Posons les choses calmement.

Un re-render, ce n'est pas « redessiner l'écran ». C'est : React rappelle ta fonction-composant, obtient une nouvelle description de l'UI (l'arbre de React elements), puis la compare à la précédente et n'applique au vrai écran que les différences. Cette étape de comparaison s'appelle la réconciliation, et React la fait extrêmement vite. Re-render un petit composant qui retourne trois lignes de JSX, c'est de l'ordre de quelques microsecondes. Autant dire gratuit.

Alors, qu'est-ce qui est réellement coûteux ? Trois grandes familles :

• Les calculs lourds dans le corps du composant. Filtrer ou trier un tableau de plusieurs milliers d'éléments, faire des maths sur de grosses structures, sérialiser quelque chose de volumineux. Si ce calcul se refait à chaque rendu sans raison, c'est du gâchis pur.
• Les grandes listes et les arbres profonds. Re-render un composant, c'est pas cher ; re-render des centaines de composants enfants parce que le parent a bougé, ça commence à se sentir. Un re-render de 5 nœuds : invisible. De 2000 nœuds, dont certains font des calculs : là, on peut voir le chrono d'un entraînement saccader.
• Les re-renders très fréquents. Un composant qui se redessine une fois sur un clic, on s'en moque même s'il est un peu lourd. Le même composant qui se redessine chaque seconde à cause d'un chrono, ou à chaque pixel d'un défilement, change tout : un petit coût répété 60 fois par minute devient un vrai coût.

La règle qui en découle est simple à énoncer : fréquence × coût unitaire = douleur. Un calcul cher mais rare ? On laisse. Un calcul léger mais répété 60 fois par seconde ? Souvent on laisse aussi. Un calcul cher et fréquent, sur une grosse structure ? Là, oui, on mémoïse. Tu remarqueras que l'exemple réel d'Halterofit qu'on verra plus bas coche pile cette case : un filtrage de liste qui, sans précaution, se referait à chaque tick du chrono.

3. useContext — partager sans « faire passer la prop » partout

Ton app utilise exactement ce mécanisme pour la couleur du texte des boutons. Deux fichiers se parlent à travers un contexte, sans jamais se passer de prop de couleur. Regardons les deux bouts du canal.

Étape A — on crée le canal, et le composant Text le lit :

// On crée le canal. La valeur par défaut est undefined : si personne n'a
// rien déposé au-dessus, le Text n'a aucune couleur imposée par le contexte.
const TextClassContext = React.createContext<string | undefined>(undefined);

function Text({ className, variant = 'default', ...props }) {
  // On LIT ce que le canal contient, ici et maintenant, à ce point de l'arbre.
  // Si un parent a déposé une classe de couleur plus haut, on la récupère.
  const textClass = React.useContext(TextClassContext);

  return (
    <Component
      // textClass (venu du contexte) est fusionné avec les autres classes.
      className={cn(textVariants({ variant }), textClass, className)}
      {...props}
    />
  );
}

Étape B — le Button DÉPOSE une valeur dans le canal pour tous ses enfants :

function Button({ className, variant, size, ...props }) {
  return (
    // .Provider = "je dépose CETTE valeur dans le canal pour tout ce qui est
    // à l'intérieur". value = la bonne classe de couleur selon la variante
    // (default, destructive, outline...) calculée par buttonTextVariants.
    <TextClassContext.Provider value={buttonTextVariants({ variant, size })}>
      <Pressable className={cn(/* ... */)} role="button" {...props} />
    </TextClassContext.Provider>
  );
}

Résultat presque magique : tu écris <Button><Text>Valider</Text></Button> et le Text prend automatiquement la bonne couleur, sans que tu lui passes la moindre prop de couleur. Le Button l'a déposée dans le canal, le Text l'a lue. C'est ça, useContext : lire une valeur fournie plus haut dans l'arbre, peu importe la distance.

Maintenant, un point que beaucoup ignorent et qui se relie directement à la section sur l'égalité référentielle. Le Contexte a un comportement de re-render à connaître :

De ce comportement découle une bonne habitude d'architecture : découper les contextes. Plutôt qu'un énorme contexte qui contient tout (l'utilisateur, le thème, les préférences, l'état du formulaire...), où le moindre changement réveille tout le monde, on préfère plusieurs petits contextes ciblés. Un changement de thème ne devrait pas re-render les composants qui ne lisent que l'utilisateur. Un contexte = une préoccupation qui évolue à son propre rythme. C'est plus de fichiers, mais beaucoup moins de re-renders parasites.

4. useMemo — se souvenir d'un calcul

Voici l'usage réel dans ton hook d'entraînement. On veut afficher la liste des exercices visibles : ceux chargés depuis la base de données, filtrés pour ne garder que les ids encore présents dans la session en cours.

// On veut la liste des exercices VISIBLES : ceux de la base, filtrés
// par les ids encore présents dans la session.
const exercises = useMemo(() => {
  const dbExercises = workout?.exercises ?? [];
  if (dbExercises.length === 0) return dbExercises;

  // Construire ce Set + filtrer le tableau = du vrai travail. On ne veut
  // PAS le refaire à chaque rendu : pendant un entraînement, le chrono
  // déclenche un rendu chaque seconde (voir useElapsedSeconds).
  const visibleIds = new Set(exerciseIdsKey ? exerciseIdsKey.split(',') : []);
  return dbExercises.filter((e) => visibleIds.has(e.id));
}, [workout, exerciseIdsKey]); // ◀── les ingrédients (le tableau de dépendances)

La structure est useMemo(() => { calcul }, [ingrédients]) — exactement la même forme que useEffect du module sur useState & useEffect, mais ça retourne une valeur au lieu de produire un effet de bord. Tant que workout et exerciseIdsKey gardent la même référence, React redonne le même tableau exercises sans refiltrer.

5. useCallback — le même principe, mais pour une fonction

// SANS useCallback : `onLog` est une fonction DIFFÉRENTE (nouvelle référence)
// à chaque rendu. Pour === elle n'est jamais "la même" qu'au rendu d'avant.
const onLog = () => logSet(exerciseId);

// AVEC useCallback : React garde la MÊME fonction tant que `exerciseId` ne
// change pas. Exactement la même structure que useMemo : (fonction, [deps]).
const onLog = useCallback(() => logSet(exerciseId), [exerciseId]);

Aide-mémoire : useMemo mémorise une valeur, useCallback mémorise une fonction. Les deux ne sont qu'une seule idée. D'ailleurs useCallback(fn, deps) est littéralement un raccourci pour useMemo(() => fn, deps) : « mémoïse cette fonction comme si c'était une valeur ».

Insistons sur un point que les débutants ratent souvent : useCallback seul, sur une fonction qui n'est passée à personne d'optimisé, ne sert à rien. Il ne « rend pas la fonction plus rapide ». Sa seule utilité est de stabiliser une référence pour que quelqu'un en aval (un memo, un autre useMemo, un tableau de dépendances d'useEffect) puisse constater « ah, c'est la même qu'avant, je ne bouge pas ». Sans ce destinataire, tu paies le coût de la mémoïsation sans aucun bénéfice. C'est exactement la transition vers memo.

6. memo — empêcher un composant de re-render pour rien

// MonGros est emballé dans memo : il ne se redessine QUE si ses props
// changent réellement, même si son parent re-render pour une autre raison.
const MonGros = React.memo(function MonGros({ data }) {
  return /* ... un rendu coûteux ... */;
});

Et voici le piège que tu peux maintenant anticiper tout seul, grâce à la section 1 : « props identiques », pour memo, ça veut dire mêmes références. Si tu passes en prop un objet ou une fonction fabriqués dans le parent, ils sont neufs à chaque rendu du parent. memo compare, voit une référence différente, conclut « les props ont changé » et re-render quand même. Ton memo ne sert à rien.

function Parent() {
  // PIÈGE : cet objet et cette fonction sont NEUFS à chaque rendu du Parent.
  // MonGros est memo... mais il re-render quand même, car la prop "change".
  return <MonGros data={{ x: 1 }} onPress={() => go()} />;
}

function ParentCorrige() {
  // On STABILISE les références. Maintenant memo "voit" qu'elles sont les
  // mêmes qu'avant et saute vraiment le re-render.
  const data = useMemo(() => ({ x: 1 }), []);
  const onPress = useCallback(() => go(), []);
  return <MonGros data={data} onPress={onPress} />;
}

C'est le moment où les trois outils se rejoignent.

7. Le trio qui ne marche qu'ensemble

La bonne façon de raisonner, dans cet ordre : « Ce composant enfant est-il vraiment lourd / très répété ? » → si oui, memo. « Lui passé-je des objets ou des fonctions en props ? » → si oui, stabilise-les avec useMemo / useCallback pour que le memo ne soit pas saboté. Tu n'arrives jamais à useCallback « parce que c'est mieux » ; tu y arrives parce qu'un memo précis en a besoin.

8. Le React Compiler — pourquoi tu dois comprendre sans sur-optimiser

Maintenant que tu as transpiré sur useMemo, useCallback et memo, une nouvelle qui surprend : dans Halterofit, tu vas en écrire à la main beaucoup moins que tu ne le penses. La raison s'appelle le React Compiler, et il est activé dans le projet.

Le React Compiler est un outil de build (relié à tout l'arsenal décrit dans le module sur l'outillage du projet) qui analyse ton code à la compilation et insère automatiquement la mémoïsation là où elle est utile. Concrètement, il comprend tout seul que tel objet ne dépend que de telles variables, et il fait l'équivalent d'un useMemo / useCallback / memo à ta place, sans que tu écrives ces hooks. Tu écris du code React simple et lisible, et la machine s'occupe de la plomberie d'optimisation en coulisses.

Conséquence pratique très concrète pour toi : ne sur-optimise pas à la main. Avec le Compiler activé, semer des useMemo / useCallback « au cas où » est non seulement inutile, c'est parfois contre-productif — tu ajoutes du bruit que la machine aurait géré mieux. Écris du code simple par défaut. Garde les optimisations manuelles pour les rares endroits où tu as un besoin précis et explicite, comme le filtrage du chrono. C'est moins de code à écrire, et surtout moins de code à lire pour le prochain qui passe — toi, dans trois mois.

const exercises = useMemo(() => {
  const dbExercises = workout?.exercises ?? [];
  if (dbExercises.length === 0) return dbExercises;
  const visibleIds = new Set(exerciseIdsKey ? exerciseIdsKey.split(',') : []);
  return dbExercises.filter((e) => visibleIds.has(e.id));
}, [workout, exerciseIdsKey]);