Preparing for React 19: a guide for WordPress 6.6 users

As WordPress developers, we often integrate custom React components into our themes and plugins to create dynamic and responsive user interfaces.

With the upcoming release of React 19, it’s crucial to prepare for changes and deprecations that could impact our existing codebases. WordPress 6.6, which was recently released, includes React 18.3. This version is nearly identical to 18.2 but adds warnings for deprecated features to help you prepare for React 19.

Addressing these deprecations is essential to ensure compatibility with React 19, and ignoring them can lead to bugs or issues in your custom blocks, plugins, or themes when React 19 is released and included in WordPress.

This article outlines each deprecation, provides code examples, and guides you through replacing deprecated features to maintain smooth functionality.

Removed deprecations in React

Several deprecated APIs and features have been removed to streamline the React library and encourage best practices. This section covers the key changes and how to update your code accordingly.

1. Removal of defaultProps for function components

React 19 will remove defaultProps for function components in favor of ES6 default parameters. According to the WordPress team, this deprecation is most commonly used in plugins and themes.

As a WordPress developer, you might use defaultProps to provide default values for props in your function components, ensuring that components behave correctly even if certain props are not passed.

Here is what your current code may look like with defaultProps:

function CustomButton({ label, color }) {
    return { label };
}

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

In this example, a CustomButton component has default label and color values provided by defaultProps. With React 19, this will throw a warning error, urging you to use ES6 default parameters instead.

Here is the updated code with ES6 default parameters:

function CustomButton({ label="Click me", color="blue" }) {
    return { label };
}

Using ES6 default parameters, the default values are now directly in the function signature, making the code easier to read and maintain.

2. Removal of propTypes for function components

propTypes was deprecated in React 15.5.0 and will also be completely removed in the React package in v19. If you’re using propTypes, it’s recommended that you migrate to TypeScript or another type-checking solution.

You might have been using propTypes to validate the props passed to your function components to ensure they receive the correct types and values. For example:

import PropTypes from 'prop-types';

function CustomButton({ label, color }) {
    return { label };
}

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

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

Today, you can start using TypeScript for these type-checkings:

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

const CustomButton = ({ label="Click me", color="blue" }: CustomButtonProps) => {
    return { label };
};

3. Removal of Legacy Context (contextTypes and getChildContext)

Given the longstanding nature of many plugins and codebases in WordPress, you might still be using the legacy contextTypes and getChildContext APIs in your class components. These APIs were used to pass data from a parent component to its descendants without explicitly passing props at each level.

However, it’s important to note that Legacy Context was deprecated in React 16.6.0 and will be removed in React v19. This change is intended to make React slightly smaller and faster, as the Legacy Context API had subtle bugs that were often easy to overlook.

The legacy method has been replaced with the new contextType API.

Here’s an example of how you may be using the deprecated Context API in a WordPress plugin to pass global settings, such as the site title, from a parent component to a child component without 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 ;
  }
}

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

  render() {
    return 
Site Title: {this.context.siteTitle}
;
  }
}

In contrast, the modern approach uses the createContext method. This is the method you should adopt as you prepare for React 19:

import React from 'react';

const SettingsContext = React.createContext();

class SettingsProvider extends React.Component {
  render() {
    return (
      
        
      
    );
  }
}

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

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

4. Removal of string refs

Using string refs was once a common way to access a DOM element in React components. However, they have been considered legacy since React 16.3.0 and will be removed in v19.

While string refs were straightforward, they had several issues, such as potential naming conflicts and a lack of flexibility.

Consider an example of using string refs in a WordPress custom block. Imagine you have a custom Gutenberg block that includes an input field, and you want the input field to be focused automatically when the block is added to the editor. Here’s how you might have done this using string refs:

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

  render() {
    return ;
  }
}

To prepare for React 19, you must replace string refs with callback refs or the React.createRef API. Here’s the same example using a callback ref:

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

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

5. Removal of module pattern factories

Another deprecated feature that will be removed in React 19 is module pattern factories. This pattern was rarely used and caused React to be slightly larger and slower than necessary.

Module pattern factories allowed developers to create components less conventionally. Here’s an example of how you may be using it:

function SettingsPanelFactory() {
  return {
    render() {
      return (
        

          
Settings
          {/* other settings UI components */}
        

      );
    }
  };
}

In this pattern, SettingsPanelFactory returns an object using a render method rather than returning JSX directly.

To comply with React 19, you must migrate module pattern factories to regular functions that return JSX directly. Here’s the updated example:

function SettingsPanel() {
  return (
    

      
Settings
      {/* other settings UI components */}
    

  );
}

6. Removal of createFactory API

In React 19, React.createFactory is being removed. This method was more commonly used before JSX became widely supported. It allowed developers to create React elements without using JSX syntax.

However, with the prevalence of JSX, createFactory has become obsolete and can be replaced with simpler, more readable JSX code.

Here’s an example of using createFactory to create a button element. This might be part of a custom WordPress plugin that dynamically generates button elements based on user input:

import { createFactory } from 'react';

const button = createFactory('button');

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

To update this code for React 19, replace createFactory with JSX. This change makes the code more modern, readable, and maintainable:

function CustomButton() {
  return Click Me;
}

7. Removal of react-test-renderer/shallow

React 19 removes react-test-renderer/shallow to streamline the testing utilities and encourage best practices. In React 18, react-test-renderer/shallow was updated to re-export react-shallow-renderer.

Previously, you might have used react-test-renderer/shallow to create shallow render tests for your React components:

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

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

To comply with React 19, you need to install react-shallow-renderer:

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

And update your import:

import ShallowRenderer from 'react-shallow-renderer';

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

The React team recommends migrating to the React Testing Library, which provides more robust testing practices by focusing on how users interact with your components.

To do this, install the @testing-library/react library as a dev dependency:

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

Next, you can test the same component using this modern approach:

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

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