useState & useEffect

Voici les deux outils que tu vas croiser dans presque chaque fichier de l'app. useState donne à un composant une mémoire qui survit aux re-renders. useEffect lui permet de se synchroniser avec le monde extérieur : minuteurs, abonnements, réseau. Avec le modèle mental vu dans le module sur le modèle mental de React, ces deux hooks vont passer du statut de « formule magique recopiée » à celui d'outils que tu comprends vraiment. Ce module est long et bavard exprès : il vaut mieux relire deux fois la théorie que recoller du code au hasard.

Qu'est-ce qu'un hook, au juste ?

Avant de parler de useState et useEffect en détail, il faut un mot sur la famille à laquelle ils appartiennent : les hooks. Le mot anglais hook signifie « crochet », mais le verbe to hook into something veut dire « se brancher sur, s'accrocher à » quelque chose. C'est exactement l'idée. Un hook est une fonction spéciale qui se branche sur les fonctionnalités internes de React : la mémoire, le cycle de rendu, le contexte, les optimisations. Quand tu appelles useState, tu ne fais pas qu'appeler une fonction utilitaire ordinaire — tu dis à React : « réserve-moi un emplacement de mémoire et gère-le pour moi entre les rendus ».

Avant les hooks (React, vers 2018), pour qu'un composant ait de la mémoire ou des effets de bord, il fallait l'écrire sous forme de classe, avec un vocabulaire compliqué (this.state, this.setState, des méthodes de cycle de vie aux noms à rallonge). Les hooks ont permis d'obtenir les mêmes super-pouvoirs depuis de simples fonctions, en ajoutant juste un appel comme useState(0). C'est pour ça que tout le code moderne que tu liras dans Halterofit est fait de fonctions, jamais de classes : les hooks ont rendu les classes inutiles pour 99 % des cas.

Les règles des hooks

Les hooks ne sont puissants que parce qu'ils obéissent à deux règles strictes. Elles paraissent arbitraires au début ; elles deviennent évidentes dès qu'on comprend pourquoi elles existent. Les voici :

1. Appelle les hooks seulement au niveau supérieur de ton composant. Jamais à l'intérieur d'un if, d'une boucle, d'un try/catch, ou d'une fonction imbriquée. Les appels de hooks doivent être « visibles » directement, en haut du corps de la fonction.
2. Appelle les hooks seulement depuis un composant React ou depuis un autre hook. Pas depuis une fonction JavaScript ordinaire, pas depuis un gestionnaire d'événement.

La conséquence la plus visible de la règle 1, c'est que l'ordre des appels de hooks doit rester identique d'un rendu à l'autre. Si à un rendu tu appelles trois hooks, et qu'au rendu suivant tu en sautes un parce qu'il était dans un if devenu faux, tout se décale.

// ❌ INTERDIT : un hook caché dans une condition.
function Mauvais({ connecte }) {
  if (connecte) {
    const [nom, setNom] = useState('');  // appelé seulement parfois → l'ordre saute
  }
  // ...
}

// ✅ CORRECT : le hook est toujours appelé, c'est SA VALEUR qu'on conditionne.
function Bon({ connecte }) {
  const [nom, setNom] = useState('');    // toujours appelé, toujours en 1er
  const affiche = connecte ? nom : 'invité';
  // ...
}

La parade est toujours la même : appelle le hook inconditionnellement, puis mets la condition après, sur la valeur ou dans le JSX. Ne déplace jamais l'appel lui-même.

useState : se souvenir d'une valeur entre deux re-renders

// useState retourne une PAIRE : [valeur actuelle, fonction pour la changer].
// 'Patrick' est la valeur INITIALE (utilisée seulement au tout premier render).
const [name, setName] = useState('Patrick');

//      ▲ valeur     ▲ "setter"
// Pour lire : on utilise `name`.
// Pour changer : on appelle `setName('Bob')`  →  React re-render avec name = 'Bob'.

Cette double-écriture [valeur, setValeur] s'appelle une déstructuration de tableau : useState renvoie un tableau de deux éléments, et on les nomme à la volée. La convention x / setX est universelle ; respecte-la, tout le monde la lit d'un coup d'œil.

L'état est un instantané figé (et les mises à jour sont groupées)

Voici l'idée la plus profonde de tout le module, et celle qui débloque le plus de bugs une fois comprise. Pendant un rendu donné, la valeur de l'état ne change pas. Elle est figée, comme une photo (un « instantané », un snapshot). Quand tu appelles un setter, tu ne modifies pas la valeur du rendu en cours : tu demandes à React de refaire un nouveau rendu, avec une nouvelle photo où la valeur sera à jour.

Le piège classique qui en découle :

const [count, setCount] = useState(0);

function handlePress() {
  setCount(count + 1);  // count vaut 0 ici → on demande "passe à 1"
  setCount(count + 1);  // count vaut TOUJOURS 0 ici → on redemande "passe à 1"
  setCount(count + 1);  // idem → "passe à 1"
  // Résultat : count finit à 1, pas à 3 !
}

Pourquoi ? Parce que pendant tout l'exécution de handlePress, count reste l'instantané du rendu courant : 0. Les trois lignes calculent donc trois fois 0 + 1. Surprenant la première fois, parfaitement logique une fois qu'on tient l'idée d'instantané.

Les mises à jour sont asynchrones et groupées (batching)

Deuxième surprise, liée à la première : appeler un setter ne re-render pas immédiatement. React n'interrompt pas ta fonction au milieu pour redessiner. Il note ta demande, finit d'exécuter ton gestionnaire d'événement jusqu'au bout, puis regroupe toutes les demandes accumulées et fait un seul re-render à la fin. Ce regroupement s'appelle le batching (« mise en lot »). C'est une optimisation : si tu changes cinq états dans la même fonction, l'écran ne clignote pas cinq fois, il se redessine une fois avec les cinq nouvelles valeurs.

C'est aussi pour ça que, juste après setCount(5), si tu écris console.log(count), tu verras encore l'ancienne valeur : le re-render — et donc la nouvelle photo de count — n'a pas encore eu lieu. Ce n'est pas un bug, c'est le modèle.

Bien mettre à jour : forme fonctionnelle et initialisation paresseuse

La mise à jour fonctionnelle : setX(prev => ...)

Comment alors incrémenter trois fois pour de vrai ? En passant au setter une fonction plutôt qu'une valeur. React appelle cette fonction en lui donnant la valeur la plus à jour qu'il connaît (pas l'instantané figé), et utilise ce qu'elle retourne comme nouvelle valeur. On l'appelle la mise à jour fonctionnelle ou functional update.

function handlePress() {
  setCount(prev => prev + 1);  // React : "le plus à jour vaut 0" → 1
  setCount(prev => prev + 1);  // "le plus à jour vaut 1" → 2
  setCount(prev => prev + 1);  // "le plus à jour vaut 2" → 3
  // Résultat : count finit bien à 3 ✅
}

prev n'est pas un mot magique : c'est juste le nom que tu donnes au paramètre. React le remplit pour toi avec l'état courant de la file d'attente. La règle pratique : dès que ta nouvelle valeur dépend de l'ancienne, utilise la forme fonctionnelle.

L'initialisation paresseuse : useState(() => ...)

Dernier raffinement de useState. La valeur initiale n'est utilisée qu'au tout premier rendu — ensuite, React l'ignore. Pourtant, si tu écris useState(calculLourd()), calculLourd() est appelé à chaque rendu (la fonction est évaluée avant d'entrer dans useState), même si le résultat est jeté. Gaspillage. La parade : passer une fonction à useState. React ne l'appellera qu'une fois, au premier rendu.

// ❌ calculLourd() s'exécute à CHAQUE rendu (et le résultat est ignoré après le 1er)
const [data, setData] = useState(calculLourd());

// ✅ initialisation paresseuse : la fonction n'est appelée qu'au premier rendu
const [data, setData] = useState(() => calculLourd());

Subtil mais utile : lire des données d'un stockage local, parser un gros objet, générer une valeur par défaut coûteuse… autant de cas où la forme paresseuse useState(() => ...) évite un calcul répété pour rien.

useState dans ton vrai code : l'écran d'inscription

Passons au concret. Chaque champ du formulaire d'inscription a son propre useState. C'est le motif le plus courant que tu rencontreras dans toute l'app :

// Un état par champ : la valeur tapée + de quoi la mettre à jour.
const [displayName, setDisplayName] = useState('');
const [email, setEmail] = useState('');
const [password, setPassword] = useState('');
const [confirmPassword, setConfirmPassword] = useState('');
const [showPassword, setShowPassword] = useState(false); // afficher/masquer le mot de passe
const [error, setError] = useState('');         // message d'erreur affiché
const [isLoading, setIsLoading] = useState(false); // requête en cours ?

Sept morceaux de mémoire indépendants, et — point crucial — appelés tous en haut du composant, dans le même ordre à chaque rendu : la règle des hooks est respectée. Chaque frappe au clavier appelle un setter (ex. setEmail(...)), ce qui re-render l'écran avec la nouvelle valeur dans le champ.

Note au passage la différence de nature entre ces états. email est une donnée « contenu » (ce que l'utilisateur tape). isLoading et showPassword sont des états « d'interface » : des booléens qui pilotent l'apparence (spinner affiché ? mot de passe en clair ?). error est un état « message ». Voir l'état d'un écran, c'est voir la liste de tout ce qui peut y bouger.

Et voici comment ces setters sont orchestrés au moment d'envoyer le formulaire :

const handleSignUp = async () => {
  setError('');           // 1. on efface l'ancienne erreur

  const nameErr = getDisplayNameError(displayName);
  if (nameErr) { setError(nameErr); return; }     // (les validateurs vus dans le module TypeScript)

  const emailErr = getEmailError(email);
  if (emailErr) { setError(emailErr); return; }    // email invalide → on affiche et on arrête

  // ... (mot de passe, confirmation : même schéma) ...

  setIsLoading(true);     // on passe en "chargement" (le bouton montre un spinner)
  try {
    await signUp(email, password, displayName);    // appel réseau
    router.replace({ pathname: '/(auth)/confirm-account', /* ... */ });
  } catch (err) {
    setError(/* message lisible */);  // en cas d'échec : on affiche l'erreur
  } finally {
    setIsLoading(false);  // dans tous les cas : on quitte le "chargement"
  }
};

Remarque comme isLoading pilote l'interface : pendant la requête il vaut true → le bouton affiche un spinner et les champs passent en editable={!isLoading} (désactivés) ; à la fin, retour à false. L'état décrit l'écran, et changer l'état redessine l'écran. Le finally garantit qu'on sort toujours du chargement, même si l'appel échoue.

useEffect : se synchroniser avec un système extérieur

La nuance « synchroniser, pas réagir » est subtile mais elle change tout. Exemple : tu veux un minuteur qui tourne tant que l'entraînement est actif. La mauvaise lecture (« quand l'entraînement démarre, lance un minuteur ; quand il s'arrête, arrête-le ») te pousse à écrire deux bouts de code séparés et à oublier des cas. La bonne lecture (« le minuteur doit être synchronisé avec startEpochMs ») te donne un seul effet, avec son nettoyage, et React gère démarrage, arrêt et redémarrage tout seul. C'est exactement ce que fait le hook du chrono qu'on lit plus bas.

Quand tu n'as PAS besoin d'un effet

Le meilleur useEffect est souvent celui que tu n'écris pas. Avant d'en ajouter un, pose-toi la question : est-ce que je peux calculer cette valeur directement pendant le rendu ? Si oui, n'utilise pas d'effet — calcule-la, point. Une erreur très répandue consiste à stocker dans un état une donnée qui pourrait être dérivée d'un autre état, puis à synchroniser les deux avec un effet. C'est du travail en double et une source de bugs.

// ❌ INUTILE : un état + un effet pour ce qu'on peut juste calculer
const [firstName, setFirstName] = useState('Patrick');
const [lastName, setLastName] = useState('Patenaude');
const [fullName, setFullName] = useState('');
useEffect(() => { setFullName(firstName + ' ' + lastName); }, [firstName, lastName]);

// ✅ DÉRIVÉ pendant le rendu : pas d'état superflu, pas d'effet
const fullName = firstName + ' ' + lastName;

Si le calcul est vraiment lourd et que tu veux éviter de le refaire à chaque rendu, ce n'est toujours pas un cas pour useEffect : c'est un cas pour useMemo, qu'on détaille dans le module sur useContext, useMemo, useCallback et memo. La règle : on dérive pendant le rendu, on mémoïse si c'est coûteux, et on réserve useEffect aux vrais systèmes extérieurs.

Le timing exact : après le rendu, après le commit

Quand React rend ton composant, il fait deux choses dans l'ordre : (1) il calcule le JSX (la phase de rendu, pure, sans effet de bord), puis (2) il applique le résultat à l'écran (la phase de commit). useEffect s'exécute après ces deux phases, une fois que l'écran est peint. C'est pour ça qu'on dit que les effets ne « ralentissent pas l'affichage » : l'utilisateur voit d'abord l'écran, l'effet tourne ensuite.

Ce timing explique pourquoi on ne met jamais d'effet de bord directement dans le corps du composant (pendant la phase de rendu) : le rendu doit rester pur et prévisible, comme on l'a martelé dans le module sur le modèle mental de React. Lancer un minuteur ou un appel réseau pendant le rendu casserait cette pureté. useEffect est précisément la porte de sortie propre vers le monde extérieur, ouverte au bon moment.

L'anatomie en 3 parties

Tout useEffect bien écrit a trois parties. On va les voir sur un hook réel de ton app, puis disséquer chacune en profondeur :

export function useElapsedSeconds(startEpochMs: number | null): number {
  const [elapsed, setElapsed] = useState(0);

  useEffect(() => {
    // ── PARTIE 1 : l'effet (ce qu'on met en place) ──
    if (startEpochMs == null) return;  // pas de minuteur si pas de départ

    const tick = () =>
      setElapsed(Math.max(0, Math.floor((Date.now() - startEpochMs) / 1000)));

    const timeout = setTimeout(tick, 0);      // une fois, presque tout de suite
    const interval = setInterval(tick, 1000); // puis chaque seconde

    // ── PARTIE 2 : le nettoyage (renvoyé sous forme de fonction) ──
    return () => {
      clearTimeout(timeout);    // on arrête les minuteurs quand on s'en va
      clearInterval(interval);  // SINON : fuite mémoire + minuteurs en double
    };
  }, [startEpochMs]); // ── PARTIE 3 : les dépendances ──

  return startEpochMs == null ? 0 : elapsed;
}

Partie 1 — l'effet : ce qu'on met en place

La fonction passée à useEffect est l'effet : le code qui établit la synchronisation avec le système extérieur. Ici, le système extérieur, ce sont les minuteurs du moteur JavaScript (setTimeout et setInterval). L'effet commence par une garde : if (startEpochMs == null) return; — s'il n'y a pas d'heure de départ, il n'y a rien à synchroniser, donc on ne crée aucun minuteur. Quitter tôt comme ça est parfaitement valide : un effet a le droit de ne rien faire.

Ensuite, on définit tick : à chaque appel, il recalcule le nombre de secondes écoulées depuis le départ, à partir de l'horloge réelle Date.now(), et met elapsed à jour via son setter. On l'arme deux fois : un setTimeout(tick, 0) pour afficher la bonne valeur immédiatement (utile si on reprend un entraînement déjà en cours), puis un setInterval(tick, 1000) pour rafraîchir chaque seconde. Le commentaire d'en-tête du fichier — celui que la méthode du module sur la lecture d'un fichier inconnu t'apprend à lire en premier — souligne un choix malin : on dérive le temps depuis l'horloge à chaque tick au lieu d'accumuler un compteur. Résultat : si le téléphone met l'app en arrière-plan et gèle le fil JavaScript, le chrono restera juste au retour, car il se recale sur l'heure réelle plutôt que de compter des ticks manqués.

Partie 2 — le nettoyage : ce qu'on défait

Si ton effet renvoie une fonction, React l'appelle la fonction de nettoyage (cleanup). React l'exécute dans deux situations : (a) juste avant de relancer l'effet (parce qu'une dépendance a changé), et (b) quand le composant est démonté (il disparaît de l'écran). Le principe : tout ce que l'effet a « branché » doit être « débranché » par le nettoyage. Tu as ouvert une connexion ? Ferme-la. Tu t'es abonné ? Désabonne-toi. Tu as armé un minuteur ? Désarme-le.

Ici, le nettoyage appelle clearTimeout et clearInterval pour stopper les deux minuteurs. Sans lui, ce serait la catastrophe décrite dans le commentaire : à chaque changement de startEpochMs, on créerait un nouvel interval sans arrêter l'ancien. Les minuteurs s'accumuleraient (deux, trois, dix qui tournent en parallèle), chacun appelant setElapsed, et le compteur se mettrait à sauter ou clignoter — sans parler de la fuite mémoire, puisque ces minuteurs zombies retiennent en vie tout ce qu'ils touchent. Le nettoyage n'est pas une politesse optionnelle ; c'est la moitié de l'effet.

Partie 3 — les dépendances : quand l'effet rejoue

Le deuxième argument de useEffect, ici [startEpochMs], est le tableau de dépendances. Il répond à une seule question : quand faut-il relancer l'effet ? React compare, d'un rendu à l'autre, chaque valeur du tableau à la précédente. Si au moins une a changé, il lance le nettoyage de l'ancien effet, puis exécute l'effet à nouveau. Si rien n'a changé, il laisse l'effet en place, intact.

L'exhaustivité du tableau (et ce qui arrive si tu triches)

Règle d'or : le tableau doit contenir toutes les valeurs réactives que l'effet utilise — toute variable, prop ou état lu à l'intérieur de l'effet et susceptible de changer. C'est ce qu'on appelle l'exhaustivité des dépendances, et le linter de React te le rappelle à coups d'avertissements. Pourquoi cette rigueur ? Parce qu'un effet doit refléter l'état le plus récent. S'il lit startEpochMs mais que tu l'omets du tableau, l'effet ne se relancera pas quand startEpochMs changera : il continuera de calculer avec l'ancienne valeur, capturée la première fois. C'est le fameux bug de la « valeur périmée » (stale closure).

La tentation, quand un effet se relance « trop souvent », est de retirer des dépendances du tableau pour le faire taire. Ne fais jamais ça : tu ne corriges pas le problème, tu le caches, et tu fabriques une valeur périmée. La vraie solution est presque toujours de restructurer : sortir du code de l'effet, transformer une valeur en mise à jour fonctionnelle (setX(prev => ...), qui ne dépend plus de l'état lu), ou stabiliser une fonction avec useCallback (voir le module sur useContext, useMemo, useCallback et memo). Le tableau de dépendances n'est pas un réglage de confort : c'est une déclaration de vérité sur ce dont dépend ton effet.

Les erreurs classiques de useEffect

Presque tous les bugs de useEffect tombent dans l'une de ces trois familles. Les reconnaître à la lecture te fera gagner des heures.

1. La boucle infinie

Symptôme : l'app rame, chauffe, le compteur de rendus explose. Cause typique : l'effet met à jour un état qui figure dans ses propres dépendances. L'effet change l'état → l'état change → React relance l'effet → l'effet change encore l'état → … à l'infini.

// ❌ BOUCLE INFINIE : l'effet écrit `count`, et `count` est dans les deps.
const [count, setCount] = useState(0);
useEffect(() => {
  setCount(count + 1);  // change count → relance l'effet → change count → ...
}, [count]);

La parade dépend de l'intention. Souvent, c'est qu'on n'avait pas besoin d'un effet du tout (valeur dérivable pendant le rendu). Parfois, il faut juste retirer la dépendance circulaire et utiliser une mise à jour fonctionnelle. Mais d'abord : pose-toi la question « cet effet a-t-il lieu d'être ? ».

2. Le nettoyage oublié (la fuite)

Symptôme : ralentissements progressifs, comportements en double, avertissements du type « tentative de mise à jour d'un composant démonté ». Cause : l'effet branche quelque chose (minuteur, abonnement, écouteur d'événement) mais ne renvoie pas de nettoyage pour le débrancher. À chaque relance ou à chaque changement d'écran, les ressources s'empilent. C'est exactement la fuite que useElapsedSeconds évite grâce à ses clearTimeout / clearInterval. Règle mnémotechnique : tout ce qui s'ouvre dans un effet doit se fermer dans le nettoyage.

3. Les dépendances incomplètes (la valeur périmée)

Symptôme : « ça marchait au début mais ça ne se met plus à jour ». L'effet a capturé une valeur au premier rendu et ne l'a jamais rafraîchie, parce qu'on a oublié (ou retiré) une dépendance. L'effet lit une vieille photo. C'est insidieux parce qu'il n'y a ni plantage ni boucle — juste une valeur qui « se coince ». La parade : déclarer honnêtement toutes les dépendances, et restructurer si l'effet se relance alors trop souvent (voir la section sur l'exhaustivité plus haut).

Un mot sur useRef, pour le contraste

Pour bien cerner useState, il aide d'en voir l'opposé. useRef est aussi une boîte de mémoire stable qui survit aux re-renders — mais avec une différence capitale : changer son contenu ne déclenche AUCUN re-render. C'est une boîte « silencieuse ». Tu y accèdes via sa propriété .current.

// useState : changer la valeur → re-render (l'écran se met à jour)
const [count, setCount] = useState(0);
setCount(1);          // → React redessine

// useRef : changer .current → AUCUN re-render (valeur retenue, écran inchangé)
const ref = useRef(0);
ref.current = 1;      // → rien ne se redessine

Le critère de choix tient en une phrase : si une valeur doit apparaître à l'écran quand elle change, c'est useState. Si tu as juste besoin de retenir quelque chose sans que ça redessine quoi que ce soit, c'est useRef.

return startEpochMs == null ? 0 : elapsed;