It's odd that we see some warnings in the unit test on this PR but not when I did the React 18.3 upgrade.

Indeed. Maybe they tinkered with some feature flags between 18.3 and 19 beta.

If I understand correctly, many of the test warnings seem to be because of how Ariakit retrieves the ref prop, it falls back to element.ref:

https://github.com/ariakit/ariakit/blob/73eca3904b97615a9fbc8c82eef7bc3afc86dae1/packages/ariakit-react-core/src/utils/misc.ts#L44

and that yields a warning in React 19. At the same time, I assume Ariakit will stay compatible with older React versions where ref was still handled specially.

@diegohaz @DaniGuardiola any idea if we're planning to do anything about these warnings in Reakit?

@diegohaz could Ariakit possibly use some sort of React version detection instead and use it to determine what to do, rather than this fallback system that creates warnings?

That part was updated to avoid those warnings (ref: https://x.com/diegohaz/status/1780794744534163888). But apparently it's not enough?

I still don't know the idiomatic way to fix that.

@diegohaz @DaniGuardiola I actually tried updating to the latest Ariakit version in this branch and it seems to resolve those warnings 👍

Dani has started working on the update in #60992, and here we have one more reason to move it forward.

Updated to the RC. Hoping to have some time next week to play more thoroughly with it.

Size Change: +15.1 kB (+0.2%)

Total Size: 7.68 MB

_{compressed-size-action}

Fixed some tests, most of them were pretty straightforward. At first glance, the mobile tests seem to be failing because RN uses an old React version - we'll need a RN update to support React 19.

FYI, Framer Motion will be a blocker for now. More context: #60975

React 19.0.0-rc.0. is out.

This is the exact build we'll release as 19.0, unless an issue is reported that requires a breaking change.

Source: https://x.com/acdlite/status/1797668537349328923

I also wonder if facebook/react#29585 could be an issue for the block editor. Potentially, it can affect block re-ordering, but it will need some testing.

Seems like we'll need to wait a bit for now, re https://x.com/sophiebits/status/1801663976973209620?s=46 and https://tkdodo.eu/blog/react-19-and-suspense-a-drama-in-3-acts

Happy to retry this once the release gets unblocked once more.

The suspense issue doesn’t affect our codebase, so we could try the latest RC.

Updated to the latest RC.

We'll still need to wait for RN support:

callstack/react-native-testing-library#1593

See callstack/react-native-testing-library#1698 for RN support for React 19 (hopefully H1 2025)

A few updates as I've been experimenting with making React 19 work in the meantime:

• Bumped to the latest React 19 RC in 63ac11d
• Removed the now-unnecessary Ariakit patch in c557a6e
• Removed the umd builds once more in 2d1ac29
• Added a meta box container check to fix some errors in 39d6d4c
• Fixed InserterBox rendering in 3e8a81a
• Bumped framer-motion to the latest v12 alpha which introduces React 19 support in 6a9ada3

I'm experimenting with using <link /> for loading separate component stylesheets on demand in #66781

I'm experimenting with using for loading separate component stylesheets on demand in #66781

IIRC, we can also use suspense around components loading assets on demand and defer rendering. It could help render different previews.

The react@19.0.0-rc.1 has been released - facebook/react#29898 (comment).

The react@19.0.0-rc.1 has been released - facebook/react#29898 (comment).

Thanks for the heads up. A few updates:

• Bumped to the latest version in 87bf928
• Moved framer-motion dependency to the root to make it patchable in 9a566e6
• Patched framer-motion@12.0.0-alpha.1 types to make type check pass in 0ae8c13 - this is temporary, see React 19 motiondivision/motion#2667)
• Using motion.create() instead of motion() in 7a5e4b1
• Updated useSuspenseSelect tests to pass in 31f99c3 (worth deep-diving into this, but FWIW suspense was overhauled in React 19)

Haven't done thorough testing, but it could be in a testable state at this point.

Next steps: There are some failing e2e tests, we need to investigate why and fix the cause.

Note: React Native is still a blocker: callstack/react-native-testing-library#1698

React v19 is now stable - https://react.dev/blog/2024/12/05/react-19.

It seems that the biggest blocker here would be React Native.

We're not exporting any of the new APIs 😅 This could also contribute to the developer note story-telling about the new features unlocked by the upgrade.

Before just blindly adding wp-element exports of all the new API, I'm curious if we already have Gutenberg use cases for them. I suspect that some of the additions are useful only with React Server Components, which we don't use.

Some new APIs are enhancements or replacements for what we already use. We can ditch useEvent from wp-compose in favor of useEffectEvent. The new cleanup functions for refs obsolete useRefEffect. use will be also useful for fetching and context.

I'm not sure about all the "actions" APIs: useActionState, useFormStatus, Activity. This looks useful mainly for RSCs. Maybe usable also for purely client apps, but certainly not the main audience.

What do we lose by exposing them? I think if we're to maintain @wordpress/element as a light wrapper around React, we'll have to expose them for proper React 19 compat.

However, if you ask me, the right solution to this issue is to just retire @wordpress/element altogether.

However, if you ask me, the right solution to this issue is to just retire @wordpress/element altogether.

I think we're returning to this subject every year :) Here's the general convo - #62939.

On the inserter metric changes: I'm assuming this has something to do with the changes to iframe portal rendering that are part of the upgrade.

@tyxla I tried to isolate the iframe loading changes to their own PR. Turns out it's also possible with React 18: #76314. The only difference is the need to auto-delete the duplicate body element.

The performance tests in this isolated PR don't show any significant changes for inserterHover. Even all other metric changes are non-significant, i.e., the difference between trunk and PR branches is of similar size as the variation between samples on the same branch.

Another big change is successfully split off the main PR 👍

What do we lose by exposing them? I think if we're to maintain @wordpress/element as a light wrapper around React, we'll have to expose them for proper React 19 compat.

I'll actually add all the extra exports so that we can discuss specifics, but generally exposing all new APIs, even the ones clearly related to RSC, feels pointless.

I'll actually add all the extra exports so that we can discuss specifics

You can now see the actual new APIs in f31d2be. Everything that's new in react-dom and react is now exported.

I have biggest doubts about the functions like prefetchDNS or preloadModule. The reason why they are in React at all is that they have different implementations in browser, SSR mode and RSC mode. Each platform treats them differently. For a browser-only app, they don't add much value.

I have biggest doubts about the functions like prefetchDNS or preloadModule. The reason why they are in React at all is that they have different implementations in browser, SSR mode and RSC mode. Each platform treats them differently. For a browser-only app, they don't add much value.

I see what you mean, and I agree they don't necessarily add much value. I still think it is possible to consume them on a package level, and that could potentially be useful for someone. I'm fine with keeping them exported if it doesn't come with any negatives, even if it's mostly for consistency with the public React APIs. And I still maintain the perspective that @wordpress/element should go away in the long term, so ideally none of these calls will really matter much.