React 19 est sorti en décembre 2024, et c'est l'année de correctifs et d'affinages qui a suivi, jusqu'à React 19.2, qui a rendu ses deux plus gros paris exploitables en production : le React Compiler et les Server Components. React 19 a aussi apporté les Actions pour les formulaires et les mutations, le hook use, les métadonnées de document natives, ref comme prop simple, et Context comme son propre provider. Si vous êtes encore sur React 18, voici ce qui a changé et si la migration en vaut la peine.

React 18 vs React 19 en un coup d'oeil

Lisez ce tableau comme une carte. Le compiler est le changement qui transforme le travail au quotidien ; le reste est incrémental.

Le React Compiler : fini la mémoïsation manuelle

React 18 imposait useMemo, useCallback et React.memo aux développeurs pour éviter les re-renders inutiles. Le React Compiler analyse le code des composants à la compilation et insère cette mémoïsation automatiquement. Aucun changement de comportement, les mêmes règles React, juste moins de renders gaspillés sans le boilerplate. En 2026, le compiler a atteint une version stable et tourne en production à grande échelle.

// React 18 : mémoïsation manuelle pour éviter les re-renders
function ProductList({ products, onSelect }) {
  const sorted = useMemo(() => [...products].sort((a, b) => a.price - b.price), [products]);
  const handleSelect = useCallback((id) => onSelect(id), [onSelect]);

  return sorted.map((p) => <ProductRow key={p.id} product={p} onClick={handleSelect} />);
}

// React 19 + Compiler : le compiler insère la mémoïsation à votre place
function ProductList({ products, onSelect }) {
  const sorted = [...products].sort((a, b) => a.price - b.price);
  return sorted.map((p) => <ProductRow key={p.id} product={p} onClick={() => onSelect(p.id)} />);
}

Ce qu'il ne fait pas, c'est rendre une app lente rapide tout seul. Il supprime les re-renders gaspillés, ce qui compte pour les grandes listes et les arbres profonds, mais un appel réseau lent ou une requête sans index reste lent. Vérifiez qu'il fonctionne via les React DevTools : les valeurs et composants mémoïsés affichent un badge compiler, et le profiler devrait montrer moins de commits à l'interaction.

Les Server Components comme pattern par défaut

Les React Server Components sont passés de la fonctionnalité du App Router de Next.js à un pattern largement adopté en 2026, avec un support dans plus de frameworks et un chemin autonome via un bundler compatible. Un Server Component se rend côté serveur, peut lire directement la base de données ou le système de fichiers, et n'envoie aucun JavaScript au client pour cette partie de l'arbre. Les Client Components, marqués par la directive use client, gèrent toujours tout ce qui est interactif.

// Ce composant n'envoie jamais sa logique au navigateur
async function ProductPage({ params }) {
  const product = await db.products.findUnique({ where: { id: params.id } });

  return (
    <div>
      <h1>{product.name}</h1>
      <AddToCartButton productId={product.id} /> {/* composant client */}
    </div>
  );
}

Le changement de modèle mental, c'est de trier vos composants selon ce qui a besoin du navigateur, state, effects, gestionnaires d'événements, par rapport à ce qui n'en a pas besoin, récupération de données et markup statique. Le défaut devient le serveur, et vous passez au client seulement là où vit l'interactivité.

Le piège, c'est la frontière entre les deux. Tout ce qui est passé d'un Server Component à un Client Component en prop doit être sérialisable, donc une fonction ou une instance de classe ne peut pas la traverser. En pratique, vous passez des données simples vers le bas et gardez la logique interactive dans le Client Component. Bien placer ces frontières, c'est l'essentiel de la courbe d'apprentissage.

Les Actions : formulaires et mutations sans le boilerplate

React 19 ajoute un modèle de première classe pour le travail async déclenché par l'utilisateur. useActionState suit l'état pending et error d'une action, useFormStatus permet à un composant imbriqué de lire l'état de soumission du formulaire parent sans prop drilling, et useOptimistic affiche un résultat optimiste pendant que l'action tourne. Ensemble, ils suppriment l'essentiel de l'état loading et error que vous écriviez à la main autour d'un formulaire.

function UpdateName() {
  const [error, submitAction, isPending] = useActionState(
    async (previous, formData) => {
      return await updateName(formData.get('name')); // renvoie une chaîne d'erreur ou null
    },
    null,
  );

  return (
    <form action={submitAction}>
      <input name="name" />
      <button disabled={isPending}>Enregistrer</button>
      {error && <p role="alert">{error}</p>}
    </form>
  );
}

Les métadonnées de document directement dans les composants

React rend désormais les balises title, meta et link n'importe où dans l'arbre de composants et les remonte dans le head du document. Pour des métadonnées SEO simples, cela remplace react-helmet et la gestion manuelle du head : les balises vivent à côté du composant qui possède la donnée. Des frameworks comme Next.js offrent toujours une API de métadonnées plus riche avec du templating et des helpers Open Graph, mais une app React simple obtient l'essentiel gratuitement.

function ProductPage({ product }) {
  return (
    <article>
      <title>{product.name} | Ma Boutique</title>
      <meta name="description" content={product.shortDescription} />
      <h1>{product.name}</h1>
    </article>
  );
}

Les petits changements quality-of-life

• ✓ref comme prop : les composants fonction reçoivent ref directement, forwardRef n'est plus nécessaire.
• ✓Context comme son propre provider : <ThemeContext value={theme}> au lieu de <ThemeContext.Provider value={theme}>.
• ✓use() : lire une promesse ou un contexte dans le render, y compris conditionnellement, ce que les hooks n'ont jamais pu faire.
• ✓Les erreurs d'hydratation affichent maintenant un diff de ce que le serveur et le client ont rendu, au lieu d'un avertissement générique.
• ✓Les ref callbacks peuvent renvoyer une fonction de cleanup, donc une ref peut se monter et se démonter comme un effect.

Faut-il migrer depuis React 18 ?

Oui, et le risque est faible pour la plupart des apps. React 19 est en grande partie rétrocompatible. Les breaking changes sont la suppression d'API dépréciées depuis des années, string refs, legacy context, defaultProps sur les composants fonction, propTypes et module pattern factories, et des codemods officiels gèrent l'essentiel. Migrez d'abord, corrigez les dépréciations, puis adoptez le Compiler et les Server Components à votre rythme. Rien n'oblige à réécrire quoi que ce soit pour en profiter.

FAQ

Quelle est la principale différence entre React 18 et React 19 ?

React 19 automatise la mémoïsation avec le Compiler et fait des Server Components et des Actions des citoyens de première classe, là où React 18 laissait les trois au développeur ou au framework. Tout le reste est incrémental.

Faut-il le React Compiler pour utiliser React 19 ?

Non. Le Compiler est un plugin de build en opt-in. React 19 fonctionne sans lui, et vous continuez à écrire useMemo et useCallback à la main là où le profiling montre que ça compte.

Les Server Components, c'est seulement pour Next.js ?

Plus maintenant. Ils ont commencé là mais sont désormais supportés dans plusieurs frameworks et peuvent tourner en autonome avec un bundler compatible. Next.js reste l'implémentation la plus complète.

React 19, migration difficile ?

En général non. C'est en grande partie rétrocompatible, et les breaking changes suppriment des API dépréciées depuis longtemps. Les codemods s'occupent de l'essentiel du travail.

Le fil rouge de React 19, c'est de supprimer du travail que vous faisiez à la main : mémoïsation, plomberie de données côté serveur, état de formulaire, balises de head. Migrez quand c'est pratique, puis adoptez le Compiler et les Server Components là où ils sont rentables, sans réécriture.