Element: add polyfills for render, hydrate, unmountComponentAtNode - #78899

Size Change: +952 B (+0.01%)

Total Size: 8.21 MB

_{compressed-size-action}

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: jsnajdr <jsnajdr@git.wordpress.org>
Co-authored-by: simison <simison@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: peterwilsoncc <peterwilsoncc@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Tested a few popular plugins with WP 7.0.

• Without Gutenberg (React 18)
• With Gutenberg trunk (React 19)
• With this branch (React 19 + polyfill)

React 19 without Polyfill:

• Yoast SEO: fails with Uncaught TypeError: Cannot read properties of undefined (reading '1') (in dashboard and in editor)
• Fluent Forms works but throws error Uncaught TypeError: (0 , import_data.combineReducers) is not a function
• Elementor: fails with Uncaught TypeError: Cannot read properties of undefined (reading 'ReactCurrentDispatcher')
• Sure Cart: fails with Uncaught TypeError: Cannot read properties of undefined (reading 'ReactCurrentOwner') (in the product editor)

React 19 with polyfill, a few continue to be broken:

• Yoast SEO: fails with Uncaught TypeError: Cannot read properties of undefined (reading '1') (in dashboard and in editor)
• Sure Forms: fails with Uncaught TypeError: Cannot read properties of undefined (reading 'ReactCurrentOwner')
• Sure Cart: fails with Uncaught TypeError: Cannot read properties of undefined (reading 'ReactCurrentOwner') (in the product editor)

Everything resumed to work when disabling Gutenberg, i.e. when on React 18.

Additionally tested also Ninja Forms, Google Site Kit, Wordfence, WP Mail SMTP, Gravityforms, WPForms Lite, Hostinger Tools, Monsterinsights, Fluent Forms, and Rank Math.

My testing isn't super precise/isolated as I have multiple plugins enabled at the same time, but curious if others can replicate.

I don't think these are blockers to merging (things are better).

Error details

→ Uncaught TypeError: Cannot read properties of undefined (reading '1')

React 19 stopped applying defaultProps on function components (including forwardRef). Yoast still relies on:
defaultProps: { as: “h1”, ... } for Title component.

→ Uncaught TypeError: Cannot read properties of undefined (reading 'ReactCurrentOwner')

Sure Forms seems to be referencing React internals via this code in dashboard.js:

var n = r(51609)
, o = Symbol.for("react.element")
, i = Symbol.for("react.fragment")
, a = Object.prototype.hasOwnProperty
, s = n.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED.ReactCurrentOwner
, l = {
  key: !0,
  ref: !0,
  __self: !0,
  __source: !0
};

Strangely, when trying to test this in the post editor, it looks like React 18 is still being used there?

This is indeed strange, the only explanation is that Gutenberg plugin is not active. Can you check the URLs of the react and react-dom scripts, and possibly other wp-* scripts, and verify they are coming from the plugin, not from Core?

Strangely, when trying to test this in the post editor, it looks like React 18 is still being used there?

This is indeed strange, the only explanation is that Gutenberg plugin is not active. Can you check the URLs of the react and react-dom scripts, and possibly other wp-* scripts, and verify they are coming from the plugin, not from Core?

I'll check again, but I was simultaneously seeing React.version showing 18 while also seeing the changes to wp.element.render in this branch (i.e. deprecation warnings) taking effect, which would imply the plugin was active.

I'll check again, but I was simultaneously seeing React.version showing 18 while also seeing the changes to wp.element.render in this branch (i.e. deprecation warnings) taking effect, which would imply the plugin was active.

This must have been a temporary issue. It seems to be working now.

Separately, one thing I'm observing in doing some edge-case testing switching between wp.element.render and ReactDOM.render on the same element is an error about "You are calling ReactDOMClient.createRoot() on a container that has already been passed to createRoot() before." At a glance it seems that the copy of react-polyfill-base is duplicated between @wordpress/element and ReactDOM, so each has their own roots WeakMap. Would we expect those roots to be shared? Or edge-case enough to not worry about?

React 19 stopped applying defaultProps on function components

This is much worse than missing render because we cannot polyfill this, and it breaks a major plugin.

n.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED.ReactCurrentOwner

This could be used to determine which component is currently rendering, but with React 19 it's completely gone. The internals are now called __DOM_INTERNALS_DO_NOT_USE_OR_WARN_USERS_THEY_CANNOT_UPGRADE and their shape is different, ReactCurrentOwner is not there.

Flaky tests detected in 06092f4.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/26897624655
📝 Reported issues:

• [Flaky Test] shouldn't conflict with server-side autosave #78706 in /test/e2e/specs/editor/various/autosave.spec.js

At a glance it seems that the copy of react-polyfill-base is duplicated between @wordpress/element and ReactDOM, so each has their own roots WeakMap. Would we expect those roots to be shared?

Yes, this is an unpleasant edge case, there are two copies of the polyfill, not compatible with each other because of separate root maps.

The reason is that @wordpress/element can't really import render from react-dom, the following import would fail, because the export doesn't exist:

import { render } from 'react-dom';

It exists only on the window.ReactDOM global, but not in the NPM package, and neither it's present in the @types/react type definitions.

I don't know how to share the implementation between the two scripts, so I decided to duplicate.

In practice hopefully this never happens. The consumer should use only one render, imported from one package or the other.

I don't know how to share the implementation between the two scripts, so I decided to duplicate.

One idea (which I think maybe React itself has used?) might be to assign a custom property on the DOM element itself to track its root? But yeah, ideally this wouldn't happen in practice 😅

might be to assign a custom property on the DOM element itself to track its root?

Either this, or to put the root map on the window, in some semi-secret way (symbol key, non-enumerable etc.)