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: +12.1 kB (+0.63%)

Total Size: 1.93 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.

Won't have a chance to work on this anymore this week. Next up on my mind are:

• Editor iframe content doesn't always load (progress here)
• Move away from deprecated umd builds; keep an eye on the react vendor chunks vs the element one
• We're still using v18 types
• Clean up the branch from the fixes and patches that we eventually reverted.

Editor iframe content doesn't always load

Looks like I figured this out: it was related to how we were handling iframe content loading and rendering. See this thread for more info and d4b4827 as the solution that did the job.

The majority of e2e tests should start passing after this fix. 🤞

We'll still need to test a bunch of the places that handle communication between the parent frame and the iframe. I'm expecting that's what causing the rest of the e2e failures.

It seems the remaining e2e test failures are related to the inert attribute with Pattern Overrides.

It seems the remaining e2e test failures are related to the inert attribute with Pattern Overrides.

Looks like it, but I think we have a bigger issue, but I'll comment about it shortly.

Going to do a rebase to clean up unnecessary commits and consolidate some of the changes, which will also help with rebasing in the future.

As I'm working to land independent pieces of the PR, it looks like we still have a major issue with how iframes and their events are handled. One can encounter it easily when there's communication happening between the iframe and the parent frame. One example path:

• Go to /wp-admin/site-editor.php?p=%2Fpattern
• In the search field, type b or c
• Witness a couple of errors:

I haven't done a research yet, and I might be unable to do thorough research this week, but this appears like something in React 19 changed how we're working with iframes. I wonder if this is an opportunity to revisit the pre-existing iframe load hacks, or how we're handling srcDoc with blobs.

This might be an interesting puzzle for y'all: @ellatrix @Mamaduka @jsnajdr.

@tyxla, I pushed some more fixes for the inert attribute.

I believe the mentioned error is related to StrictMode and the changes introduced to useCallback in React 19. The useRefEffect uses this hook internally with logic to mimic a cleanup method. I'll continue debugging this.

I cannot reproduce the error when running the app in production mode, using SCRIPT_DEBUG: false and a prod build.

P.S. I found a different error when SCRIPT_DEBUG: false and using the dev build for the plugin. This can be a common combo when developing or debugging the project.

Screenshot