useRef — ce que c’est, le hook de référence et le travail avec le DOM dans React

Qu’est-ce que useRef dans React

useRef est un hook ajouté dans React 16.8 qui retourne un objet ref mutable avec une seule propriété .current. La valeur initiale est attribuée à .current lors du montage du composant. La principale différence avec une variable ordinaire est que l’objet ref survit aux re-rendus : lors des rendus suivants, React ne recrée pas le ref mais retourne le même objet.

En interne, useRef utilise le même mécanisme que useState et useEffect — une liste chaînée de hooks sur le nœud fiber. Cependant, contrairement à useState, React ne suit pas les modifications de l’objet ref, ne met pas en file d’attente les mises à jour et ne planifie pas de re-rendu. Cela fait de useRef un hook extrêmement léger sans impact sur les performances, même en cas de modifications fréquentes.

Selon l’équipe React — Hooks FAQ (2025), useRef est essentiellement une « boîte » qui stocke une valeur. Sucre syntaxique : const ref = useRef(valeurInitiale) équivaut à const ref = { current: valeurInitiale } à la différence que React garantit que l’objet ref sera le même à chaque rendu. Pas de magie — juste une référence stable gérée par React.

import { useRef } from 'react';

function Component() {
    const countRef = useRef(0);
    // countRef.current = 0 initialement
    // countRef.current = 5 après mutation
    // Aucun re-rendu ne se produit !
}

Accès aux éléments DOM avec useRef

Le cas d’utilisation le plus courant de useRef est l’accès direct à un élément DOM. React attribue à elementRef.current une référence au nœud DOM après le montage du composant. Cela est nécessaire pour focuser une saisie, mesurer les dimensions d’un élément, intégrer des bibliothèques d’animation et des bibliothèques qui n’utilisent pas le rendu React.

React gère automatiquement les références ref sur le DOM : lors du montage, il attribue le nœud DOM réel ; lors du démontage, il le remet à null. Cela garantit que .current contient toujours la valeur à jour et empêche les fuites mémoire via des références pendantes à des éléments supprimés. Aucun nettoyage manuel n’est requis.

function AutoFocusInput() {
    const inputRef = useRef(null);

    useEffect(() => {
        // Focuser la saisie après le montage du composant
        inputRef.current?.focus();
    }, []);

    return <input ref={inputRef} type="text" />;
}

Selon la documentation React — Refs et DOM (2025), n’utilisez pas ref pour des opérations déclaratives — ouvrir/fermer des modales, gérer la visibilité. Pour ces fins, il existe state et props. Les refs sont destinées aux opérations impératives qui ne peuvent pas être exprimées de manière déclarative : focus, sélection de texte, intégration avec des bibliothèques tierces.

Stockage de valeurs mutables sans re-rendu

Le deuxième cas d’utilisation le plus important est le stockage de valeurs arbitraires qui doivent persister entre les rendus mais dont les modifications ne doivent pas déclencher de re-rendu. Exemples typiques : identifiants de minuteurs (setInterval/setTimeout), drapeaux d’annulation de requêtes, valeurs précédentes de props pour comparaison et toutes données n’affectant pas la sortie de l’interface.

C’est particulièrement utile dans useEffect : useRef stocke l’identifiant du minuteur et le nettoyage le supprime. Si timerId était stocké dans useState, chaque appel à setTimerId provoquerait un re-rendu inutile qui n’est nécessaire ni pour la logique ni pour l’interface. useRef résout ce problème sans surcharge et sans re-rendus inutiles.

function Timer() {
    const intervalRef = useRef(null);

    const start = () => {
        intervalRef.current = setInterval(() => {
            console.log('tic');
        }, 1000);
    };

    const stop = () => {
        clearInterval(intervalRef.current);
    };

    useEffect(() => stop, []);

    return <><button onClick={start}>Start</button><button onClick={stop}>Stop</button></>;
}

useRef vs useState : quand utiliser quoi

Le dilemme principal — choisir entre useRef et useState — se résout par une question : « Un re-rendu est-il nécessaire lors du changement de valeur ? ». Si oui — useState. Si non — useRef. useState stocke l’état qui affecte la sortie du composant ; useRef stocke les données nécessaires à la logique interne mais n’affectant pas l’interface.

En pratique, les développeurs utilisent souvent useRef pour stocker des callbacks afin d’éviter les problèmes de fermeture. Par exemple, si useEffect s’abonne à un événement et que le callback nécessite l’état actuel — stockez le callback dans useRef. À chaque rendu, mettez à jour ref.current avec une nouvelle fonction, et l’effet invoquera toujours le callback frais sans besoin de se réabonner.

Il existe un anti-patron : utiliser useRef pour des données nécessaires dans JSX mais dont les modifications ne doivent pas provoquer de re-rendu. Cela entraîne une désynchronisation — l’interface affiche des données anciennes alors que ref.current est déjà nouveau. Si la valeur est affichée dans l’interface — utilisez useState. Si elle est utilisée uniquement en interne — useRef.

useRef en combinaison avec useEffect

La combinaison useRef + useEffect est le modèle standard pour suivre les valeurs précédentes des props. Stockez la valeur précédente dans ref, comparez-la avec la valeur actuelle dans useEffect et prenez des décisions basées sur la différence. C’est particulièrement utile dans les animations quand vous avez besoin de connaître la valeur avant le changement.

function PriceDisplay({ price }) {
    const prevPriceRef = useRef(price);

    useEffect(() => {
        const prevPrice = prevPriceRef.current;
        if (price > prevPrice) {
            animateUp();
        } else if (price < prevPrice) {
            animateDown();
        }
        prevPriceRef.current = price;
    }, [price]);

    return <span>${price}</span>;
}

Selon la documentation React — Hooks FAQ (2025), ce modèle est appelé « modèle de valeur précédente ». Il fonctionne car useRef conserve la valeur entre les rendus et useEffect s’exécute après la confirmation des modifications. D’abord le DOM est mis à jour avec le nouveau price, ensuite useEffect le compare avec le précédent (encore dans ref) et met à jour ref.current à la valeur actuelle.

Erreurs courantes avec useRef

L’erreur la plus fréquente est la lecture de ref.current pendant la phase de rendu pour calculer du JSX. Comme modifier ref.current ne déclenche pas de re-rendu, le composant peut utiliser une valeur obsolète. Si .current participe à la sortie de l’interface — utilisez useState. Si vous devez synchroniser ref et state, utilisez useEffect pour mettre à jour state à partir de ref.

• Ref dans JSX — lire ref.current dans une fonction de rendu entraîne une désynchronisation entre l’interface et les données.
• Ref comme dépendance de useEffect — ref.current ne doit pas être dans le tableau de dépendances ; React ne suit pas ses modifications.
• Vérification null oubliée — au démontage ref.current devient null ; vérifiez avant d’accéder.
• Stockage de fonctions dans ref — mettez à jour ref.current à chaque rendu si vous utilisez le modèle de callback frais.

// ❌ Ne lisez pas ref.current pendant le rendu pour l’affichage
function BadComponent() {
    const valRef = useRef(0);
    return <p>{valRef.current}</p>; // NE sera PAS mis à jour lors de la mutation
}

// ✅ Utilisez state pour l’affichage, ref pour la logique
function GoodComponent() {
    const [val, setVal] = useState(0);
    const valRef = useRef(0);
    return <p>{val}</p>;
}

Une autre erreur courante est d’utiliser useRef comme seul moyen de stocker l’état dans un composant alors que les données affectent réellement l’interface. Les développeurs choisissent useRef pour éviter les re-rendus « inutiles », mais se retrouvent avec une interface qui ne se met pas à jour. L’approche correcte : utilisez useState pour les données d’interface et useRef uniquement pour les valeurs auxiliaires ne participant pas au rendu.