React 19 a posé les bases fin 2024, puis le React Compiler est passé stable en version 1.0 en octobre 2025. Mais c'est une autre release, plus discrète, qui change réellement le code que tu écris au quotidien : React 19.2, sortie le 1er octobre 2025. Pas de nouveau paradigme cette fois, juste trois outils qui répondent à des problèmes que tout développeur React a déjà rencontrés sans forcément avoir de solution propre.

Trois ajouts concentrent l'essentiel : le hook useEffectEvent, qui règle enfin le problème des closures obsolètes dans les Effects ; le composant Activity, qui introduit un état intermédiaire entre "monté" et "démonté" ; et cacheSignal, qui permet d'annuler proprement du travail côté serveur devenu inutile. À cela s'ajoute une amélioration du rendu SSR qui réduit le scintillement des Suspense boundaries.

Si tu es resté sur React 19.0 ou 19.1 en attendant que le Compiler se stabilise, voici ce que ces changements apportent concrètement, avec du code avant/après.

useEffectEvent : en finir avec les closures obsolètes

Le problème est connu de quiconque a écrit un useEffect avec plusieurs dépendances : certaines valeurs doivent déclencher une re-synchronisation de l'effet, d'autres non, mais React ne fait pas la différence. Résultat classique : un effet de connexion qui se relance à chaque changement de thème, alors que le thème ne sert qu'à afficher une notification.

Avant 19.2, la solution consistait à stocker la valeur dans une ref pour la lire sans la déclarer comme dépendance :

function ChatRoom({ roomId, theme }) {
  // Contournement : on synchronise une ref à la main
  const themeRef = useRef(theme);
  useEffect(() => {
    themeRef.current = theme;
  });

  useEffect(() => {
    const canal = creerConnexion(roomId);
    canal.subscribe('connected', () => {
      showNotification('Connecté !', themeRef.current);
    });
    canal.connect();
    return () => canal.disconnect();
  }, [roomId]); // theme volontairement absent, mais c'est fragile
}

Avec useEffectEvent, on extrait la logique "événementielle" (qui doit toujours voir la dernière valeur, sans jamais provoquer de re-exécution) dans une fonction dédiée :

import { useEffect, useEffectEvent } from 'react';

function ChatRoom({ roomId, theme }) {
  const notifierCanal = useEffectEvent(() => {
    // Voit toujours le theme le plus récent, sans figurer dans les deps
    showNotification('Connecté !', theme);
  });

  useEffect(() => {
    const canal = creerConnexion(roomId);
    canal.subscribe('connected', notifierCanal);
    canal.connect();
    return () => canal.disconnect();
  }, [roomId]); // plus besoin de ref ni de règle de lint à contourner
}

Deux règles à retenir : une fonction créée par useEffectEvent ne peut être appelée que depuis un Effect ou un gestionnaire d'événement (jamais pendant le rendu), et elle ne doit pas être passée en dépendance d'un autre Effect — ce n'est pas nécessaire, sa référence est stable par design. Le hook est stable en 19.2, tu peux l'utiliser sans flag expérimental.

Activity : un troisième état entre monté et démonté

Jusqu'ici, pour cacher une partie de l'UI, tu avais deux options : la démonter (perte de l'état, des effets qui se relancent au retour) ou la cacher en CSS avec display: none (l'état survit, mais les effets continuent de tourner en arrière-plan — timers, abonnements, requêtes). Le composant Activity introduit un troisième comportement, pensé pour ce cas précis.

Il prend une prop mode qui vaut "visible" (par défaut) ou "hidden" :

en visible, les enfants sont affichés et leurs effets tournent normalement ;
en hidden, le DOM est masqué, les effets sont nettoyés (donc les timers et abonnements s'arrêtent bel et bien), mais l'état des composants et le DOM lui-même sont conservés en mémoire.

Au retour en mode visible, les effets sont recréés et l'UI réapparaît exactement comme elle était laissée. Le cas d'usage typique : un système d'onglets où l'utilisateur ne doit pas perdre un brouillon en cours de saisie en changeant d'onglet.

import { Activity, createElement as h, Fragment } from 'react';

function Tabs({ current }) {
  return h(Fragment, null,
    h(Activity, { mode: current === 'accueil' ? 'visible' : 'hidden' },
      h(Accueil)),
    // Le brouillon tapé ici survit au changement d'onglet
    h(Activity, { mode: current === 'contact' ? 'visible' : 'hidden' },
      h(FormulaireContact))
  );
}

En JSX classique, cela s'écrit avec deux blocs Activity dont le mode bascule selon l'onglet actif, chacun enveloppant le composant correspondant.

Autre usage intéressant : le pré-rendu. En montant un contenu avec mode="hidden" dès le départ, React le rend en arrière-plan à faible priorité, sans bloquer l'affichage de ce que l'utilisateur voit réellement — utile pour préparer un panneau ou une route probable avant que l'utilisateur ne la demande.

cacheSignal : arrêter le travail serveur devenu inutile

Cette API cible les React Server Components. Elle s'utilise avec cache(), la fonction qui mémoïse un calcul ou un appel réseau pour la durée d'un rendu serveur. Le problème qu'elle résout : sans mécanisme d'annulation, un fetch lancé pendant le rendu continue même si React n'a plus besoin du résultat (rendu abandonné, erreur ailleurs dans l'arbre, client déconnecté). Ce sont des requêtes réseau et du calcul serveur gaspillés pour rien.

cacheSignal(), appelée pendant le rendu, retourne un AbortSignal lié à la durée de vie du cache courant. Quand ce cache expire, le signal est déclenché, et tu peux t'en servir pour annuler proprement une requête :

import { cache, cacheSignal } from 'react';

const getUser = cache(async (id) => {
  const signal = cacheSignal(); // undefined hors rendu serveur
  const res = await fetch(`/api/users/${id}`, { signal });
  return res.json();
});

Point important : côté client, cacheSignal() retourne toujours null. C'est une API strictement réservée aux Server Components — logique, puisque la notion de "durée de vie d'un rendu serveur" n'a pas d'équivalent côté navigateur.

SSR : les Suspense boundaries se révèlent groupées

Dernier changement, plus discret mais visible à l'usage : à partir de 19.2, React regroupe les révélations des limites Suspense rendues côté serveur avant le premier affichage. Concrètement, si une page contient plusieurs sections en attente de données (un fil d'actualité, une barre latérale, des recommandations), leurs fallbacks respectifs se résolvent ensemble plutôt que d'apparaître un par un dans un ordre imprévisible. Le résultat perçu par l'utilisateur est moins de scintillement et une mise en page qui se stabilise en un seul mouvement au lieu de plusieurs sauts successifs.

À cela s'ajoute un ajout côté outillage : des pistes personnalisées dans les profils de performance Chrome DevTools, qui donnent enfin de la visibilité sur l'ordonnancement interne de React — utile pour diagnostiquer pourquoi un rendu prend plus de temps que prévu.

Comment migrer sans prendre de risque

Ces quatre ajouts sont additifs : aucun ne casse de code existant, et tu peux les adopter un par un.

Mets à jour vers react@19.2 et react-dom@19.2 (ou une version ultérieure de la branche 19.2, la dernière au moment de la rédaction étant 19.2.8). Si tu utilises Next.js, vérifie que ta version du framework a bien adopté cette version de React avant de migrer en profondeur.
Repère un effet avec contournement par ref dans ton code — c'est le candidat idéal pour une première conversion vers useEffectEvent. Le gain est immédiat en lisibilité et supprime une source classique de bugs liés aux dépendances de useEffect.
Teste Activity sur un seul composant à état, typiquement un système d'onglets ou une modale récurrente, avant de le généraliser. Vérifie que les effets que tu attends de voir coupés (abonnements, polling) le sont bien en mode hidden.
cacheSignal ne concerne que les Server Components — si ton architecture repose sur Next.js App Router ou un framework équivalent avec RSC, c'est un ajout à coût nul dès que tu utilises cache() avec des appels réseau.

Rien ici n'exige une réécriture. Mais si ton code contient encore des useRef qui n'existent que pour contourner les règles des dépendances, c'est le bon moment pour les faire disparaître.

React 19.2 : Activity, useEffectEvent et cacheSignal décryptés