En tant que développeurs WordPress, nous intégrons souvent des composants React personnalisés dans nos thèmes et nos extensions pour créer des interfaces utilisateur dynamiques et réactives.

Avec la sortie prochaine de React 19, il est crucial de se préparer aux changements et aux dépréciations qui pourraient avoir un impact sur nos bases de code existantes. WordPress 6.6, qui sera publié le 16 juillet, inclut React 18.3. Cette version est presque identique à la 18.2 mais ajoute des avertissements pour les fonctionnalités dépréciées afin de t’aider à te préparer à React 19.

Il est essentiel de tenir compte de ces dépréciations pour assurer la compatibilité avec React 19. Les ignorer peut entrainer des bugs ou des problèmes dans vos blocs personnalisés, vos extensions ou vos thèmes lorsque React 19 sera publié et inclus dans WordPress.

Cet article décrit chaque dépréciation, fournit des exemples de code et vous guide dans le remplacement des fonctionnalités dépréciées pour maintenir une fonctionnalité fluide.

Déprécations supprimées dans React

Plusieurs API et fonctionnalités dépréciées ont été supprimées pour rationaliser la bibliothèque React et encourager les meilleures pratiques. Cette section couvre les principaux changements et la façon de mettre à jour votre code en conséquence.

1. Suppression de defaultProps pour les composants de fonction

React 19 supprimera defaultProps pour les composants de fonction en faveur des paramètres par défaut ES6. Selon l’équipe de WordPress, cette dépréciation est le plus souvent utilisée dans les extensions et les thèmes.

En tant que développeur WordPress, vous plourriez utiliser defaultProps pour fournir des valeurs par défaut pour les props dans vos composants de fonction, ce qui garantit que les composants se comportent correctement même si certaines props ne sont pas passées.

Voici à quoi peut ressembler ton code actuel avec defaultProps:

function CustomButton({ label, color }) {
    return <button style={{ backgroundColor: color }}>{ label }</button>;
}

CustomButton.defaultProps = {
    label: 'Click me',
    color: 'blue',
};

Dans cet exemple, un composant CustomButton a des valeurs par défaut label et color fournies par defaultProps. Avec React 19, cela provoquera une erreur d’avertissement, vous incitant à utiliser plutôt les paramètres par défaut ES6.

Voici le code mis à jour avec les paramètres par défaut ES6 :

function CustomButton({ label = 'Click me', color = 'blue' }) {
    return <button style={{ backgroundColor: color }}>{ label }</button>;
}

En utilisant les paramètres par défaut ES6, les valeurs par défaut se trouvent maintenant directement dans la signature de la fonction, ce qui rend le code plus facile à lire et à maintenir.

2. Suppression des propTypes pour les composants de fonction.

propTypes a été déprécié dans React 15.5.0 et sera également complètement supprimé dans le package React dans la v19. Si tu utilises propTypes, il est recommandé de migrer vers TypeScript ou une autre solution de vérification de type.

Vous avez peut-être utilisé propTypes pour valider les props passés à vos composants de fonction afin de vous assurer qu’ils reçoivent les bons types et les bonnes valeurs. Par exemple :

import PropTypes from 'prop-types';

function CustomButton({ label, color }) {
    return <button style={{ backgroundColor: color }}>{ label }</button>;
}

CustomButton.defaultProps = {
    label: 'Click me',
    color: 'blue',
};

CustomButton.propTypes = {
    label: PropTypes.string,
    color: PropTypes.string,
};

Aujourd’hui, vous pouvez commencer à utiliser TypeScript pour ces vérifications de type :

type CustomButtonProps = {
    label?: string;
    color?: string;
};

const CustomButton = ({ label = 'Click me', color = 'blue' }: CustomButtonProps) => {
    return <button style={{ backgroundColor: color }}>{ label }</button>;
};

3. Suppression des contextes hérités (contextTypes et getChildContext)

Étant donné l’ancienneté de nombreuses extensions et bases de code dans WordPress, il se peut que vous utilisiez encore les anciennes API contextTypes et getChildContext dans vos composants de classe. Ces API étaient utilisées pour transmettre des données d’un composant parent à ses descendants sans passer explicitement des props à chaque niveau.

Cependant, il est important de noter que le contexte hérité a été déprécié dans React 16.6.0 et sera supprimé dans React v19. Ce changement vise à rendre React légèrement plus petit et plus rapide, car l’API Legacy Context comportait des bugs subtils qu’il était souvent facile de négliger.

La méthode héritée a été remplacée par la nouvelle API contextType.

Voici un exemple de la façon dont vous pouvez utiliser l’API Contexte dépréciée dans une extension WordPress pour transmettre des paramètres globaux, tels que le titre du site, d’un composant parent à un composant enfant sans prop drilling :

import PropTypes from 'prop-types';

class SettingsProvider extends React.Component {
  static childContextTypes = {
    siteTitle: PropTypes.string.isRequired,
  };

  getChildContext() {
    return { siteTitle: 'My WordPress Site' };
  }

  render() {
    return <SettingsConsumer />;
  }
}

class SettingsConsumer extends React.Component {
  static contextTypes = {
    siteTitle: PropTypes.string.isRequired,
  };

  render() {
    return <div>Site Title: {this.context.siteTitle}</div>;
  }
}

En revanche, l’approche moderne utilise la méthode createContext. C’est cette méthode que vous devrez adopter en vous préparant à React 19 :

import React from 'react';

const SettingsContext = React.createContext();

class SettingsProvider extends React.Component {
  render() {
    return (
      <SettingsContext value={{ siteTitle: 'My WordPress Site' }}>
        <SettingsConsumer />
      </SettingsContext>
    );
  }
}

class SettingsConsumer extends React.Component {
  static contextType = SettingsContext;

  render() {
    const { siteTitle } = this.context;
    return <div>Site Title: { siteTitle }</div>;
  }
}

4. Suppression des refs de chaines de caractères

L’utilisation des string refs était autrefois un moyen courant d’accéder à un élément DOM dans les composants React. Cependant, elles sont considérées comme un héritage depuis React 16.3.0 et seront supprimées dans la v19.

Si les string refs étaient simples, elles présentaient plusieurs problèmes, tels que des conflits de noms potentiels et un manque de flexibilité.

Prenons un exemple d’utilisation des string refs dans un bloc personnalisé WordPress. Imaginez que vous avez un bloc Gutenberg personnalisé qui inclut un champ de saisie, et que vous souhaitez que le champ de saisie soit mis au point automatiquement lorsque le bloc est ajouté à l’éditeur. Voici comment vous auriez pu faire cela en utilisant des refs de chaine :

class CustomBlock extends React.Component {
  componentDidMount() {
    this.refs.input.focus();
  }

  render() {
    return <input ref="input" placeholder="Enter text..." />;
  }
}

Pour te préparer à React 19, tu dois remplacer les string refs par des callback refs ou l’API React.createRef. Voici le même exemple en utilisant un callback ref:

class CustomBlock extends React.Component {
  componentDidMount() {
    this.input.focus();
  }

  render() {
    return <input ref={(input) => (this.input = input)} placeholder="Enter text..." />;
  }
}

5. Suppression des usines de modèles de modules

Une autre fonctionnalité dépréciée qui sera supprimée dans React 19 est les usines de motifs de modules. Ce modèle était rarement utilisé et faisait que React était légèrement plus grand et plus lent que nécessaire.

Les usines de compositions de modules permettaient aux développeurs de créer des composants de manière moins conventionnelle. Voici un exemple de la façon dont tu l’utilises peut-être :

function SettingsPanelFactory() {
  return {
    render() {
      return (
        <div className="settings-panel">
          <h2>Settings</h2>
          {/* other settings UI components */}
        </div>
      );
    }
  };
}

Dans ce modèle, SettingsPanelFactory renvoie un objet à l’aide d’une méthode render plutôt que de renvoyer directement du JSX.

Pour être en conformité avec React 19, tu dois faire migrer les fabriques de motifs de modules vers des fonctions régulières qui renvoient directement JSX. Voici l’exemple mis à jour :

function SettingsPanel() {
  return (
    <div className="settings-panel">
      <h2>Settings</h2>
      {/* other settings UI components */}
    </div>
  );
}

6. Suppression de l’API createFactory

Dans React 19, React.createFactory est en cours de suppression. Cette méthode était plus couramment utilisée avant que JSX ne soit largement pris en charge. Elle permettait aux développeurs de créer des éléments React sans utiliser la syntaxe JSX.

Cependant, avec la prévalence de JSX, createFactory est devenu obsolète et peut être remplacé par un code JSX plus simple et plus lisible.

Voici un exemple d’utilisation de createFactory pour créer un élément button. Cela peut faire partie d’une extension WordPress personnalisé qui génère dynamiquement des éléments button en fonction des entrées de l’utilisateur :

import { createFactory } from 'react';

const button = createFactory('button');

function CustomButton() {
  return button({ className: 'custom-button', type: 'button' }, 'Click Me');
}

Pour mettre à jour ce code pour React 19, remplace createFactory par JSX. Ce changement rend le code plus moderne, plus lisible et plus facile à maintenir :

function CustomButton() {
  return <button className="custom-button" type="button">Click Me</button>;
}

7. Suppression de react-test-renderer/shallow

React 19 supprime react-test-renderer/shallow pour rationaliser les utilitaires de test et encourager les meilleures pratiques. Dans React 18, react-test-renderer/shallow a été mis à jour pour réexporter. react-shallow-renderer.

Auparavant, vous pouviez utiliser react-test-renderer/shallow pour créer des tests de rendu peu profonds pour tes composants React :

import ShallowRenderer from 'react-test-renderer/shallow';

test('MyComponent shallow render', () => {
  const renderer = new ShallowRenderer();
  renderer.render(<MyComponent />);
  const result = renderer.getRenderOutput();
  expect(result.type).toBe('div');
});

Pour être en conformité avec React 19, vous devez installer react-shallow-renderer:

npm install react-shallow-renderer --save-dev

Et mettre à jour votre import :

import ShallowRenderer from 'react-shallow-renderer';

test('MyComponent shallow render', () => {
  const renderer = new ShallowRenderer();
  renderer.render(<MyComponent />);
  const result = renderer.getRenderOutput();
  expect(result.type).toBe('div');
});

L’équipe React recommande de migrer vers la bibliothèque de test React, qui offre des pratiques de test plus robustes en se concentrant sur la façon dont les utilisateurs interagissent avec tes composants.

Pour cela, installez la @testing-library/react en tant que dépendance dev :

npm install @testing-library/react --save-dev

Ensuite, vous pouvez tester le même composant en utilisant cette approche moderne :

import { render, screen } from '@testing-library/react';
import MyBlock from './MyBlock';

test('MyBlock renders correctly', () => {
  render(<MyBlock />);
  const element = screen.getByText('MyBlock content');
  expect(element).toBeInTheDocument();
});

Suppression des dépréciations dans React DOM

React DOM a également changé dans React 19, avec la suppression de certaines méthodes dépréciées. Cette section présente ces changements et vous guide dans la mise à jour de ton code lié au DOM.

1. Suppression de l’API react-dom/test-utils

L’API react-dom/test-utils sera également supprimée dans React 19. Cela a un impact sur la façon dont nous écrivons des tests pour nos composants React. Plus précisément, l’utilitaire act a été déplacé de react-dom/test-utils vers le paquet react.

De plus, la plupart des autres utilitaires de react-dom/test-utils ont été supprimés. Voici comment adapter tes tests pour qu’ils soient conformes à ces changements.

L’utilitaire act est essentiel pour s’assurer que toutes les mises à jour liées à tes tests ont été traitées et appliquées au DOM. Dans React 19, vous devez importer act directement depuis react au lieu de react-dom/test-utils.

// Before
import { act } from 'react-dom/test-utils';

// Now
import { act } from 'react';

L’équipe React recommande également de migrer vos tests vers la bibliothèque de tests React pour une expérience de test moderne et bien prise en charge. Voici quelques cas d’utilisation courants et comment les mettre à jour.

L’utilitaire renderIntoDocument sera supprimé. Vous pouvez le remplacer par render à partir de @testing-library/react.

// Before
import { renderIntoDocument } from 'react-dom/test-utils';

renderIntoDocument(<Component />);

// Now
import { render } from '@testing-library/react';

render(<Component />);

De même, l’utilitaire Simulate pour simuler des évènements sera supprimé. Vous devrez plutôt utiliser fireEvent de @testing-library/react, qui envoie un évènement réel sur l’élément.

// Before
import { Simulate } from 'react-dom/test-utils';

const element = document.querySelector('button');
Simulate.click(element);

// Now
import { fireEvent } from '@testing-library/react';

const element = document.querySelector('button');
fireEvent.click(element);

Sachez que fireEvent envoie un événement réel, ce qui signifie qu’il interagit avec l’élément de manière plus naturelle que les évènements synthétiques créés par Simulate. Pour bien comprendre la bibliothèque de test React, lisez sa documentation.

2. Suppression de l’API findDOMNode

Un autre changement important à venir dans React 19 est la suppression de ReactDOM.findDOMNode, qui a été dépréciée dans React 16.6.0.

Cette fonction était utilisée pour accéder au nœud DOM sous-jacent d’un composant React, mais elle présentait plusieurs inconvénients, tels que la lenteur d’exécution, la fragilité au refactoring et la rupture des niveaux d’abstraction.

À la place, vous devrez utiliser les refs DOM, qui fournissent un moyen plus fiable et plus efficace d’interagir avec les éléments DOM dans tes composants React.

Voici un exemple d’utilisation de findDOMNode pour sélectionner le texte d’un champ de saisie lors du montage du composant :

import { findDOMNode } from 'react-dom';

function AutoselectingInput() {
  useEffect(() => {
    const input = findDOMNode(this);
    input.select()
  }, []);

  render() {
    return <input defaultValue="Hello" />;
  }
}

Pour mettre à jour ce code pour React 19, remplacez findDOMNode par un ref… Cette modification rend le code plus robuste et l’aligne sur les pratiques modernes de React :

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

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

  useEffect(() => {
    inputRef.current.select();
  }, []);

  return <input ref={inputRef} defaultValue="Hello" />;
}

3. Suppression de l’API render

Avec React 19, la méthode ReactDOM.render sera supprimée. Cette méthode a été dépréciée dans React 18.0.0 en faveur de l’API createRoot de react-dom/client, qui offre un moyen plus efficace et plus moderne d’initialiser et de rendre les applications React. Ce changement fait partie des efforts continus de React pour rationaliser et optimiser la bibliothèque.

Dans une configuration WordPress typique, vous pouvez avoir un bloc personnalisé ou une extension qui initialise une application React lorsque le DOM est prêt. Auparavant, vous utilisiez ReactDOM.render:

import { render } from 'react-dom';
render(<App />, document.getElementById('root'));

Avec React 19, vous devez utiliser createRoot pour initialiser et effectuer le rendu de votre application React :

import { createRoot } from 'react-dom/client';
const root = createRoot(document.getElementById('root'));
root.render(<App />);

4. Suppression de l’API unmountComponentAtNode

React 19 supprime également la méthode ReactDOM.unmountComponentAtNode, qui était dépréciée dans React 18.0.0. Cette méthode était utilisée pour démonter un composant React du DOM.

Dans React 19, vous devrez migrer vers l’utilisation de la méthode root.unmount(), qui est plus alignée sur l’API mise à jour pour la création et l’hydratation des racines.

// Before
unmountComponentAtNode(document.getElementById('root'));

// Now
root.unmount();

5. Suppression de l’API hydrate

ReactDOM.hydrate a été déprécié dans React 18 et sera complètement supprimé dans React 19.

La nouvelle méthode de l’API client React DOM, hydrateRoot, remplace ReactDOM.hydrate, offrant un moyen plus efficace et plus moderne d’hydrater les applications React rendues par le serveur.

Dans un contexte WordPress, vous pourrez utiliser le rendu côté serveur (SSR) pour fournir le contenu HTML initial afin d’accélérer le chargement des pages. Pour hydrater ce contenu dans une application React interactive, vous utilisiez auparavant ReactDOM.hydrate:

import { hydrate } from 'react-dom';
import App from './App.js';

hydrate(
  <App />,
  document.getElementById('root')
);

Avec React 19, vous devez utiliser hydrateRoot à partir de react-dom/client pour l’hydratation :

import { hydrateRoot } from 'react-dom/client';
import App from './App.js';

hydrateRoot(
  document.getElementById('root'),
  <App />
);

Suppression des types TypeScript dépréciés

Les développeurs WordPress utilisent souvent TypeScript pour ajouter la sécurité des types et améliorer la qualité du code dans les composants React. Avec React 19, plusieurs types TypeScript dépréciés ont été supprimés ou déplacés vers des paquets plus pertinents.

Il est crucial de comprendre ces changements pour s’assurer que votre base de code reste robuste et compatible avec la dernière version de React.

Pour faciliter la transition, l’équipe React a mis à disposition un outil appelé. types-react-codemod, qui peut automatiquement mettre à jour votre base de code pour gérer ces changements.

Pour l’utiliser, exécutez la commande codemod suivante, qui inclut plusieurs transformations pour mettre à jour les types dépréciés.

npx types-react-codemod@latest preset-19 ./path-to-app

L’outil propose également un mode interactif dans lequel vous pouvez choisir des transformations spécifiques à appliquer :

? Pick transforms to apply (Press  to select,  to toggle all,  to invert selection, and  to proceed)
❯◯ context-any
◉ deprecated-react-type
◉ deprecated-sfc-element
◉ deprecated-sfc
◉ deprecated-stateless-component
◯ implicit-children
◯ useCallback-implicit-any

Voyons quelques changements clés à l’aide d’exemples.

1. Ref cleanup nécessaire

Avec React 19, les fonctions de nettoyage ref améliorent la sécurité des types en imposant des retours explicites dans les rappels ref. Les retours implicites peuvent amener TypeScript à mal interpréter la valeur de retour.

// Before
 (instance = current)} />

// Now
 { instance = current }} />

2. useRef nécessite un argument

Auparavant, useRef pouvait être appelé sans argument, ce qui entraînait des problèmes de type potentiels. Dans React 19, useRef nécessite un argument pour s’assurer que les refs sont toujours mutables.

// Before — @ts-expect-error: Expected 1 argument but saw none
useRef();

// Now — correct usage with an argument
useRef(undefined);

3. Modifications du type TypeScript de ReactElement

Le type par défaut des props ReactElement est passé de any à unknown, ce qui améliore la sécurité des types en exigeant une gestion explicite des types inconnus.

// Previously, this was 'any'
type Example = ReactElement["props"];

// Now, this is 'unknown'
type Example = ReactElement["props"];

Si votre code s’appuyait sur any, vous devez le mettre à jour pour gérer explicitement unknown ou le caster en any.

Résumé

En tant que développeurs WordPress, il est crucial de rester à jour avec les dernières avancées de React. Ce guide vous assure de comprendre les différents changements à venir dans React afin que tu puisses les appliquer à vos projets WordPress.

Une dernière information : Avec React 19, la nouvelle transformation JSX sera nécessaire. La bonne nouvelle, c’est qu’elle est déjà fournie avec WordPress 6.6. Si la nouvelle transformation n’est pas activée, vous verrez cet avertissement :

Your app (or one of its dependencies) is using an outdated JSX transform. Update to the modern JSX transform for faster performance: https://react.dev/link/new-jsx-transform

Il vous suffit d’arrêter d’utiliser les importations React pour les transformations JSX, car elles ne sont plus nécessaires.

Avons-nous manqué quelque chose ? Partagez avec nous dans la section des commentaires !

Joel Olawanle Kinsta

Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.