React 19.3 est sorti le 9 septembre 2026, et c'est une de ces versions qui ne fait pas de bruit mais qui change vraiment ton quotidien de développeur. Pas de nouveau paradigme façon Server Components, mais quatre fonctionnalités qui sortent enfin du statut expérimental : les Fragment Refs, le composant ViewTransition, l'API browser() et le support des Trusted Types.

Si tu avais mis ces sujets de côté en te disant "j'attendrai que ce soit stable", c'est le moment de les regarder sérieusement. On fait le tour de ce qui est utilisable en production dès aujourd'hui, avec des exemples concrets.

Petit rappel de contexte pour situer cette version : depuis février 2026, React n'appartient plus uniquement à Meta. Le projet est passé sous la React Foundation, hébergée par la Linux Foundation, avec des membres fondateurs comme Amazon, Microsoft, Vercel, Expo ou Software Mansion. Ce changement de gouvernance n'a rien changé au rythme des sorties : React continue de livrer des versions mineures régulières, et 19.3 s'inscrit dans cette continuité plutôt que de marquer une rupture.

Fragment Refs : la fin des div superflues

Combien de fois as-tu ajouté un <div> juste pour poser un ref dessus, alors qu'un <>...</> aurait suffi côté structure ? Depuis React 19.3, tu peux passer un ref directement à un Fragment.

import { Fragment, useRef } from 'react';

function Section() {
  const fragmentRef = useRef(null);

  return (
    <Fragment ref={fragmentRef}>
      <Heading />
      <Paragraph />
      <Paragraph />
    </Fragment>
  );
}

Le ref obtenu n'est pas un vrai nœud DOM (un fragment n'existe pas dans le DOM), mais une FragmentInstance qui expose un sous-ensemble de méthodes utiles : getClientRects(), getRootNode(), compareDocumentPosition(), scrollIntoView(), et surtout addEventListener / removeEventListener. Ça veut dire que tu peux écouter des événements sur un groupe d'enfants sans wrapper :

import { Fragment, useRef, useEffect } from 'react';

function ClickableGroup({ children, onClick }) {
  const fragmentRef = useRef(null);

  useEffect(() => {
    const instance = fragmentRef.current;
    if (!instance) return;

    instance.addEventListener('click', onClick);
    return () => instance.removeEventListener('click', onClick);
  }, [onClick]);

  return <Fragment ref={fragmentRef}>{children}</Fragment>;
}

C'est particulièrement pratique pour les composants de layout (listes, groupes de champs de formulaire, sections animées) où tu voulais un ref sur "tout le groupe" sans polluer le DOM avec un conteneur artificiel qui casse parfois ton CSS Grid ou Flexbox.

Le choix de limiter l'API de FragmentInstance à un sous-ensemble de méthodes n'est pas anodin : un fragment peut contenir plusieurs enfants avec des positions et des tailles différentes, donc des méthodes comme getBoundingClientRect() n'auraient pas de sens univoque. React a préféré exposer getClientRects(), qui renvoie une liste de rectangles, plutôt que d'inventer une sémantique ambiguë. Si tu migres un composant qui manipulait un ref de div vers un Fragment, vérifie que tu n'utilises pas une méthode DOM absente de cette liste avant de retirer le wrapper.

ViewTransition : des animations natives sans librairie

Le composant <ViewTransition>, expérimental depuis un moment, est maintenant stable. Il s'appuie sur la View Transition API du navigateur pour animer l'apparition, la disparition, le déplacement ou le redimensionnement d'éléments — sans Framer Motion ni GSAP pour les cas simples.

import { ViewTransition, startTransition, useState } from 'react';

function ToggleCard() {
  const [open, setOpen] = useState(false);

  return (
    <>
      <button onClick={() => startTransition(() => setOpen(!open))}>
        Basculer
      </button>
      {open && (
        <ViewTransition>
          <Card />
        </ViewTransition>
      )}
    </>
  );
}

Point important : la mise à jour doit passer par startTransition pour déclencher l'animation. Par défaut, tu obtiens un fondu enchaîné (cross-fade). Pour aller plus loin, le composant accepte des props enter, exit, update et share qui appliquent des classes CSS spécifiques à chaque phase de la transition, ou des callbacks (onEnter, onExit, onShare, onUpdate) si tu préfères piloter l'animation via la Web Animations API. La fonction addTransitionType permet même de différencier une transition "vers l'avant" d'une transition "vers l'arrière" dans une navigation.

Attention au support navigateur avant de baser une fonctionnalité clé dessus : Chromium 125+, Firefox 144+ et Safari 18.2+. En dessous, React dégrade proprement — pas d'animation, mais pas de crash non plus.

Pour une navigation avec des directions différentes (par exemple un carrousel où on va parfois à gauche, parfois à droite), addTransitionType te permet de qualifier la transition en cours et d'appliquer une classe CSS différente selon le type :

import { unstable_addTransitionType as addTransitionType, startTransition } from 'react';

function goToNext() {
  startTransition(() => {
    addTransitionType('slide-forward');
    setIndex((i) => i + 1);
  });
}

Tu peux ensuite cibler ::view-transition-old(.slide-forward) et ::view-transition-new(.slide-forward) en CSS pour définir des keyframes distinctes par direction. C'est ce genre de détail qui, avant, obligeait à embarquer une librairie complète pour un simple effet de carrousel ou de navigation par onglets.

`browser()` : sortir du rendu serveur sans bricolage

Troisième nouveauté notable : l'API use(browser()), qui remplace les habituels typeof window !== 'undefined' et autres useEffect détournés pour éviter qu'un composant ne s'exécute côté serveur.

import { use } from 'react';
import { browser } from 'react-dom';

function GeolocatedWidget() {
  use(browser()); // suspend côté serveur, jamais côté client

  const position = window.localStorage.getItem('lastPosition');
  return <p>Dernière position connue : {position}</p>;
}

Concrètement, ce composant déclenche un Suspense côté serveur (le fallback le plus proche s'affiche dans le HTML généré), mais se rend normalement une fois hydraté côté client. C'est exactement le genre de composant qui dépend de localStorage, de l'heure locale du navigateur ou d'une API DOM sans équivalent serveur. Tu gagnes en lisibilité : l'intention ("ce composant est client-only") est explicite dans le code, plutôt que cachée dans une condition.

L'ancien pattern — rendre un composant côté serveur puis le remplacer côté client via un useEffect — provoquait souvent un flash visuel ou une erreur d'hydratation quand le HTML rendu côté serveur ne correspondait pas exactement à ce que produisait le premier rendu client. Avec use(browser()), il n'y a plus de rendu serveur incorrect à corriger après coup : le fallback Suspense s'affiche directement, sans étape intermédiaire fautive.

Trusted Types : une brique de sécurité qui devient utilisable

Si ton application applique une Content-Security-Policy avec require-trusted-types-for 'script' pour se protéger des XSS basées sur le DOM, tu as peut-être déjà buté sur un comportement frustrant de React : la bibliothèque convertissait systématiquement les valeurs en chaînes de caractères ('' + value) avant de les passer aux API du DOM. Résultat, tes objets TrustedHTML ou TrustedScript se retrouvaient rétrogradés en simples strings, que le navigateur rejetait.

React 19.3 corrige ce point : les valeurs issues de tes policies Trusted Types traversent React sans coercition forcée, jusqu'aux sinks DOM (innerHTML et consorts). Si tu avais mis Trusted Types de côté à cause d'incompatibilités avec React, c'est le moment de retenter l'intégration.

Et côté Server Components

Dernier ajustement, plus discret : un Context peut désormais être rendu directement depuis un module 'use client' sans passer par un Provider intermédiaire côté serveur. Ça simplifie certains partages d'état entre composants serveur et client dans les architectures RSC, en évitant un niveau de wrapper qui n'existait que pour satisfaire les règles de composition.

Comment migrer sans casser ta prod

La bonne nouvelle : aucune de ces fonctionnalités n'est un breaking change. Elles s'ajoutent à l'API existante.

Mets à jour react et react-dom en 19.3 sur un environnement de staging d'abord, surtout si tu utilises des libs qui font des choses non documentées avec les Fragments ou le rendu serveur.
Si tu as des animations de transition d'état bricolées à coup de CSSTransition ou de classes manuelles, évalue si ViewTransition peut les remplacer pour les cas simples — tu gagneras en maintenabilité, pas nécessairement en compatibilité navigateur.
Cherche dans ton code les patterns typeof window !== 'undefined' ou les useEffect vides utilisés uniquement pour retarder un rendu au client : ce sont des candidats naturels pour use(browser()).
Si Trusted Types est sur ta roadmap sécurité, c'est le bon moment pour la relancer avec cette version.

React 19.3 : Fragment Refs et ViewTransition passent stables