feat: add support for React Compiler beta

[stipsan]

Description

The React Compiler is now in Beta:

• It has backwards compatibility with React 18
• The Working Group seeks feedback from library usage
• It now supports function outlining, a very effective memozation technique that is incredibly costly to do manually

This PR adds the React Compiler to the Studio in two ways:

1. Pre-compiling sanity and @sanity/vision

We've been testing it for some time now in these libraries:

• react-rx
• @sanity/ui
• @portabletext/editor
  And it has worked really well for us. react-rx is the only library that is fully compiled at the moment, while:
• @portabletext/editor is nearly there (9 out of 13 components compiled, 11 linter warnings left to fix)
• @sanity/ui also close, 290 out of 305 components, 10 linter warnings left to fix

Why is `@sanity/ui` reporting a higher number of bailouts (15 components) than the linter?

To see the report of components that can be compiled, run npx react-compiler-healthcheck. The eslint-plugin-react-compiler is intended to only report issues that are actionable, things you should fix that allows the component to be compiled. Thus it's normal to see discrepancies like in @sanity/ui. You can opt-in the linter to report all bailouts, including those that are due to patterns that will be supported in the future and are considered to be valid: pnpm eslint --cache --no-inline-config --no-eslintrc --ignore-pattern '**/__tests__/**' --ext .cjs,.mjs,.js,.jsx,.ts,.tsx --parser @typescript-eslint/parser --plugin react-compiler --plugin react-hooks --rule 'react-compiler/react-compiler: [error,{__unstable_donotuse_reportAllBailouts: true}]' src.

The benefit of pre-compiling is that "it just works", people userland bump their deps and the Studio is now faster ✨ It supports React 18 and upwards.

Plugin authors that use `@sanity/pkg-utils` can ship pre-compiled plugins as well

1. Install the compiler and the runtime: npm install --save-exact --save-dev babel-plugin-react-compiler@beta && npm install --save-exact react-compiler-runtime@beta (it's important that exact versions are used while in beta, and that react-compiler-runtime is a direct dependency, not in devDependencies).
2. Enable the compiler in the package.config.ts:

   babel: {reactCompiler: true},
   reactCompilerOptions: {target: '18'},

It makes sense to add it to @sanity/plugin-kit once the React Compiler itself is GA and no longer beta.

@sanity/vision

Running cd packages/@sanity/vision/src && pnpx react-compiler-healthcheck yields:

Successfully compiled 13 out of 13 components.

That doesn't mean everything is compiled though, as the main component <VisionGui /> is a class component and thus is unsupported by the React Compiler. The difficulty of auto memoizing class components was one of the motivators behind the introduction of React Hooks and the shift away from classes, and so <VisionGui /> will have to be refactored to a function component for it to be optimised fully.

sanity

Running cd packages/sanity/src && pnpx react-compiler-healthcheck yields:

Successfully compiled 1218 out of 1411 components.

86% coverage is awesome, at the same time it's important to consider that:

• The remaining components will take time to migrate, as they are complex and sensitive to regressions, for example here are some key ones:
  • <CommandList />
  • <GetFormValueProvider />
  • <RouteScope />
  • <DocumentPaneProvider />
  • <DocumentPanel />
  • <FormView />
  • <ChangesInspector />
  • <DocumentListPaneContent />
• We have class components that are not part of this list, that do need to be refactored to function components for them to be auto memoized:
  • <ArrayOfPrimitivesInput />
  • <BaseFileInput />
  • <ToolCanvasLegacy />

Until these are handled we won't see the full potential of the React Compiler, as it's not invulnerable to unstable props:

import {useEffect} from 'react'
import {OptimizedComponent} from './OptimizedComponent'

export default function UnoptimizedComponent(props) {

  useEffect(() => {
    props.onMount()
    // Because of disabling the linter, the compiler will skip over `UnoptimizedComponent` and not optimize it as it can't guarantee that memoizing it is safe from regressions
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [])


  return (
    <OptimizedComponent
      foo={['bar', 'baz']} // this creates a new array on every render, negating the memozation in OptimizedComponent that tries to prevent unnecessary rerenders
    />
  )
}

In this scenario the performance improvement on OptimizedComponent will appear minimal, until one day UnoptimizedComponent is fixed and now you'll have a dramatic delta as the React Compiler is able to deliver fine grained memoization and reduced rerenders to only what's absolutely necessary, end to end.

Also worth noting is that there are some known issues with @tanstack/react-table and the React Compiler, so I've added 'use no memo' on the affected files to disable the compiler there. The way references are used in that library is highly unsafe, and is causing React to no longer be fully reactive:

• Calling refs during render
• Returning refs during render
  And the effect it has is that when React Compiler memoizes our code, @tanstack/react-table stops re-rendering when it should because it's relying on unstable dependencies to reach eventual consistency and with the React Compiler enabled they're no longer unstable.

If we run into similar issues the best resolution is to add 'use no memo' at the top of that file so that we don't need to disable the React Compiler everywhere if a regression is discovered.

The strategy moving forward is to gradually refactor components so they can be compiled, and to work with the React Core Team and report issues or missing functionality so that the React Compiler can learn to understand patterns we use that follow the Rules of React and are safe, but not yet supported.
With this strategy we should see the Studio codebase get gradually faster, and when we hit critical coverage it'll suddenly speed up significantly when unstable props and context values no longer poke holes through the 1218 components that are memoized from the start.

2. Allow userland to opt-in to React Compiler

As mentioned in the previous section, even if something is fully memoized by the React Compiler, its performance improvements can be negated if parent components are sending props or context provider values that are unstable.
Thus custom studio components and code can have a major impact on the overall studio performance. We've seen customers face severe degradation simply because a single function given as a prop forgot to use the React.useCallback wrapper.
Such scenarios can be prevented if the React Compiler is enabled on custom studio code.

Additionally, the React Compiler Working Group is now open for everyone. Sanity users with complex studios is a treasure trove of code that can test the correctness of React Compiler, and we'll benefit from giving them the opportunity to participate in the working group, and give their feedback.

For users on React 18, opt-in involves installing react-compiler-runtime@beta as a direct dependency, and babel-plugin-react-compiler@beta as a dev dependency, and then add this to their sanity.cli.ts to enable the compiler:

import {defineCliConfig} from 'sanity/cli'

export default defineCliConfig({
  api: {
    projectId: 'abc123',
    dataset: 'production',
  },
  reactStrictMode: true,
  reactCompiler: {target: '18'},
})

For React 19 you only need babel-plugin-react-compiler@beta in your dev dependencies, and:

import {defineCliConfig} from 'sanity/cli'

export default defineCliConfig({
  api: {
    projectId: 'abc123',
    dataset: 'production',
  },
  reactStrictMode: true,
  reactCompiler: {target: '19'},
})

The official docs can then be used to decide how to adopt it, test it and more.
Until the React Compiler is stable, it's best to leave it as opt-in, and to require installing the babel-plugin-react-compiler and react-compiler-runtime dependencies in userland. It enables userland to test bugfixes that are only available on babel-plugin-react-compiler@experimental, and decouples the version we use to pre-compile sanity from userland.
Decoupling them is important, to ensure that userland with React Compiler can update deps like sanity anytime they like, without risking changes to how the React Compiler itself works and optimises their code. They are in control over that with when they update babel-plugin-react-compiler. It's also useful to have babel-plugin-react-compiler and eslint-plugin-react-compiler on the same exact version, so that they behave the same.

What to review

I've published a prerelease as pnpm add sanity@react-compiler that can be used to more accurately experience how it's like in userland.
On the Test Studio on the monorepo, due to how we enable HMR and such, it's easier to always enable the React Compiler. On our monorepo, enabling React Compiler enables it for sanity, @sanity/vision as well as custom studio code. There's no easy way on the monorepo to test scenarios where only sanity and @sanity/vision is compiled, and not userland. This is due to @sanity/pkg-utils only being used during publishing, and not on the monorepo.
Other differences are that the monorepo installs babel-plugin-react-compiler and react-compiler-runtime, so it's difficult to test what happens if userland wants to use the compiler but forgot to install these deps. pnpm add sanity@react-compiler allows you to experience that.

And with that said, there where a couple of things I'd want the CLI to do but I couldn't figure out:

We should detect if the wrong reactCompiler.target is used

If react is on version 18, then setting this should fail on sanity dev or sanity build:

{
  reactCompiler: {target: '19'}
}

as target must be 18.
Likewise, if package.json says: "react": "19.0.0-rc-f994737d14-20240522" then target should be 19.
We could warn here instead of erroring, as it'll still work, it's just not ideal as the native React Compiler runtime that ships in React 19 performs better than the react-compiler-runtime polyfill.

We should validate that react-compiler-runtime is installed

If we're on react 18 we should throw on sanity dev and sanity build if react-compiler-runtime isn't installed as a direct dependency:

{
  reactCompiler: {target: '18'}
}

These should pass if it's in the package.json that has react, react-dom, sanity and styled-components installed:

{
  "dependencies": {
    "react-compiler-runtime": "19.0.0-beta-a7bf2bd-20241110",
    "react-compiler-runtime": "0.0.0-experimental-678214a-20241111",
    "react-compiler-runtime": "beta",
    "react-compiler-runtime": "experimental",
    "react-compiler-runtime": "latest"
  }
}

If the semver includes ^, * or other in-exact ranges then it should fail as it's not safe. Only exact version numbers, or a dist-tag name, is safe.
Likewise, it shouldn't be a devDependencies nor peerDependencies.

We should validate that babel-plugin-react-compiler is installed

Since we intentionally don't ship babel-plugin-react-compiler as a direct dependency of sanity, it has to be installed in userland.
We should require it to be in devDependencies, and to follow the same semver rules as react-compiler-runtime.
Other tooling like next validates for this, as the error coming from vite if we don't is difficult to wrap your head around.

Ensure that if eslint-plugin-react-compiler is installed it is on the same version as babel-plugin-react-compiler

Both plugins ship with the same underlying compiler, and are published with the same version numbers and dist-tags. It's important that they match so that you don't end up with a linter that has warnings that the babel plugin now supports and vice versa.

Consider autoUpdates support

I didn't update @repo/package.bundle with the compiler, so studios that have --auto-updates in their sanity build, or autoUpdates: true in their sanity.cli.ts, will not see the compiler used on sanity or @sanity/vision. They will see it on their custom code, and it'll work well for react 19 users, but for react 18 there's going to be some bloat as react-compiler-runtime is bundled into the custom studio codebase, instead of using a shared dep like the way we handle react, react-dom and styled-components.

Consider easier setup, like Next.js

Next.js lets you enable the compiler with just a boolean, no need to set a target. It would b super sweet if all you needed to do was setting reactCompiler: true, and we'd then:

• automatically detect what the target should be by checking the react major that's installed.
• install babel-plugin-react-compiler@beta automatically to dev deps if needed.
• install react-compiler-runtime@beta as a direct dep if needed.

I don't know how to add those things to our CLI but if you do feel free to push commits to this PR and add it ❤

How to test and verify that it works

Components that are memoized gets a new badge in the React Devtools:

You can inspect the regular test studio deployment on this PR, or run pnpm dev, as well as pnpm dev:next-studio to see it on React 19. It's enabled on all of them (after this merges I'll remove the pnpm dev:compiled-studio and its vercel deployment as it's no longer needed).
Worst case these components should work like before, best case they'll work faster.

Additionally, the eFPS testing suite is updated to use the compiler, so its results are a good indicator of how much perf has improved.

Maintaining React Compiler deps

Renovatebot is struggling to understand how to deal with the pre-release version hashes used for deps like pnpm add react-compiler-runtime@beta.
The .github/worfklows/react-compiler.yml workflow added in this PR is already in use on other repos, the PRs it creates looks like this: sanity-io/ui#1468
It's setup to run after the weekly monday beta release [the React Core team runs](https://github.com/facebook/react/blob/989af12f72080c17db03ead91d99b6394a215564/.github/workflows/compiler_prereleases_weekly.yml#L5-L6
workflow_dispatch:).

Testing

All the testing suites, vitest, playwright, eFPS, everything is setup to use the compiler, to ensure we test it as much as possible.
I tried to setup a dual test runner setup like we do on react-rx, as it can be helpful to validate "correctness" (does the component still work the same if the compiler is turned off again), but I couldn't get it to work (maybe @bjoerge knows how?).
It might be useful to run E2E tests the same way, but when it all comes down to it it's not critical.
If something doesn't work, adding 'use no memo' at the top of that file opts it out on all these layers, allowing us to quickly test correctness whenever we need, and issue hotfixes that solves the worst case scenario of a regression, without needing to turn the compiler entirely off.

Notes for release

The sanity and @sanity/vision are now precompiled with the React Compiler.
With 1 231 out of 1 411 being compiled, we're already seeing a 20%-30% overall reduction in render time and latency. We expect that to improve significantly as we gradually refactor the remaining 180 components so they can be auto memoized.
For a few weeks now we've already been shipping our Design System @sanity/ui with React Compiler, as well as @portabletext/editor which is used by PortableText input fields, and react-rx which runs vital state management throughout the Studio codebase.

We continue to see impressive results in our profiling and analysis, and with the release of React Compiler in beta we are excited to add support for using it to auto memoize your own studio code:

pnpm add react-compiler-runtime@beta && pnpm add --save-dev babel-plugin-react-compiler@beta eslint-plugin-react-compiler@beta

yarn add react-compiler-runtime@beta && yarn add --save-dev babel-plugin-react-compiler@beta eslint-plugin-react-compiler@beta

npm install --save-exact react-compiler-runtime@beta && npm install --save-exact --save-dev babel-plugin-react-compiler@beta eslint-plugin-react-compiler@beta

And in your sanity.cli.ts add:

import {defineCliConfig} from 'sanity/cli'

export default defineCliConfig({
   api: {
      projectId: 'abc123',
      dataset: 'production',
   },
   reactStrictMode: true,
+  reactCompiler: {target: '18'},
})

If you decide to give the React Compiler a try make sure you share your feedback and experience using it with the Working Group!

Sanity Plugin authors can also ship plugins that are pre-compiled, if they're using @sanity/pkg-utils, by running:

pnpm add react-compiler-runtime@beta && pnpm add --save-dev @sanity/pkg-utils@latest babel-plugin-react-compiler@beta eslint-plugin-react-compiler@beta

yarn add react-compiler-runtime@beta && yarn add --save-dev @sanity/pkg-utils@latest babel-plugin-react-compiler@beta eslint-plugin-react-compiler@beta

npm install --save-exact react-compiler-runtime@beta && npm install --save-exact --save-dev @sanity/pkg-utils@latest babel-plugin-react-compiler@beta eslint-plugin-react-compiler@beta

and changing the package.config.ts to:

import {defineConfig} from '@sanity/pkg-utils'

export default defineConfig({
   // ...
+  babel: {reactCompiler: true},
+  reactCompilerOptions: {target: '18'},
})

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
page-building-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 19, 2024 4:50pm
performance-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 19, 2024 4:50pm
test-compiled-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 19, 2024 4:50pm
test-next-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 19, 2024 4:50pm
test-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 19, 2024 4:50pm

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
studio-workshop	⬜️ Ignored (Inspect)	Visit Preview		Nov 19, 2024 4:50pm

[socket-security]

New and removed dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher
npm/[email protected]	environment	+1	6.45 MB	react-bot
npm/[email protected]	environment	0	13.6 kB	react-bot
npm/[email protected]	environment	0	237 kB	react-bot

🚮 Removed packages: npm/[email protected], npm/[email protected], npm/[email protected]

View full report↗︎

[github-actions]

No changes to documentation

[github-actions]

⚡️ Editor Performance Report

Updated Tue, 19 Nov 2024 16:47:51 GMT

Benchmark	reference latency of sanity@latest	experiment latency of this branch	Δ (%) latency difference
article (title)	16.1 efps (62ms)	21.7 efps (46ms)	-16ms (-25.8%)	✅
article (body)	56.0 efps (18ms)	56.0 efps (18ms)	+0ms (+0.0%)	✅
article (string inside object)	17.1 efps (59ms)	23.8 efps (42ms)	-17ms (-28.2%)	✅
article (string inside array)	14.6 efps (69ms)	19.6 efps (51ms)	-18ms (-25.5%)	✅
recipe (name)	30.3 efps (33ms)	47.6 efps (21ms)	-12ms (-36.4%)	✅
recipe (description)	34.5 efps (29ms)	52.6 efps (19ms)	-10ms (-34.5%)	✅
recipe (instructions)	99.9+ efps (7ms)	99.9+ efps (6ms)	-1ms (-/-%)	✅
synthetic (title)	13.9 efps (72ms)	18.5 efps (54ms)	-18ms (-25.0%)	✅
synthetic (string inside object)	14.1 efps (71ms)	17.9 efps (56ms)	-15ms (-21.1%)	✅

efps — editor "frames per second". The number of updates assumed to be possible within a second.

Derived from input latency. efps = 1000 / input_latency

Detailed information

🏠 Reference result

The performance result of sanity@latest

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	62ms	71ms	113ms	151ms	739ms	13.8s
article (body)	18ms	20ms	27ms	116ms	411ms	6.1s
article (string inside object)	59ms	63ms	70ms	336ms	530ms	9.1s
article (string inside array)	69ms	76ms	138ms	294ms	1116ms	10.1s
recipe (name)	33ms	36ms	44ms	97ms	2ms	9.2s
recipe (description)	29ms	31ms	36ms	171ms	3ms	6.1s
recipe (instructions)	7ms	8ms	9ms	10ms	0ms	3.2s
synthetic (title)	72ms	77ms	83ms	421ms	1783ms	16.2s
synthetic (string inside object)	71ms	77ms	87ms	530ms	1826ms	10.9s

🧪 Experiment result

The performance result of this branch

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	46ms	50ms	65ms	107ms	213ms	11.7s
article (body)	18ms	20ms	27ms	171ms	209ms	5.8s
article (string inside object)	42ms	44ms	51ms	192ms	156ms	7.6s
article (string inside array)	51ms	56ms	77ms	200ms	408ms	8.2s
recipe (name)	21ms	23ms	27ms	41ms	0ms	8.6s
recipe (description)	19ms	21ms	23ms	43ms	0ms	4.7s
recipe (instructions)	6ms	9ms	10ms	16ms	0ms	3.3s
synthetic (title)	54ms	56ms	61ms	123ms	826ms	13.4s
synthetic (string inside object)	56ms	60ms	72ms	396ms	952ms	8.5s

📚 Glossary

column definitions

• benchmark — the name of the test, e.g. "article", followed by the label of the field being measured, e.g. "(title)".
• latency — the time between when a key was pressed and when it was rendered. derived from a set of samples. the median (p50) is shown to show the most common latency.
• p75 — the 75th percentile of the input latency in the test run. 75% of the sampled inputs in this benchmark were processed faster than this value. this provides insight into the upper range of typical performance.
• p90 — the 90th percentile of the input latency in the test run. 90% of the sampled inputs were faster than this. this metric helps identify slower interactions that occurred less frequently during the benchmark.
• p99 — the 99th percentile of the input latency in the test run. only 1% of sampled inputs were slower than this. this represents the worst-case scenarios encountered during the benchmark, useful for identifying potential performance outliers.
• blocking time — the total time during which the main thread was blocked, preventing user input and UI updates. this metric helps identify performance bottlenecks that may cause the interface to feel unresponsive.
• test duration — how long the test run took to complete.

[github-actions]

Component Testing Report Updated Nov 19, 2024 4:45 PM (UTC)

✅ All Tests Passed -- expand for details

File	Status	Duration	Passed	Skipped	Failed
comments/CommentInput.spec.tsx	✅ Passed (Inspect)	45s	15	0	0
formBuilder/ArrayInput.spec.tsx	✅ Passed (Inspect)	9s	3	0	0
formBuilder/inputs/PortableText/Annotations.spec.tsx	✅ Passed (Inspect)	31s	6	0	0
formBuilder/inputs/PortableText/copyPaste/CopyPaste.spec.tsx	✅ Passed (Inspect)	40s	11	7	0
formBuilder/inputs/PortableText/copyPaste/CopyPasteFields.spec.tsx	✅ Passed (Inspect)	0s	0	12	0
formBuilder/inputs/PortableText/Decorators.spec.tsx	✅ Passed (Inspect)	18s	6	0	0
formBuilder/inputs/PortableText/DisableFocusAndUnset.spec.tsx	✅ Passed (Inspect)	11s	3	0	0
formBuilder/inputs/PortableText/DragAndDrop.spec.tsx	✅ Passed (Inspect)	2m 5s	2	0	0
formBuilder/inputs/PortableText/FocusTracking.spec.tsx	✅ Passed (Inspect)	46s	15	0	0
formBuilder/inputs/PortableText/Input.spec.tsx	✅ Passed (Inspect)	1m 52s	21	0	0
formBuilder/inputs/PortableText/ObjectBlock.spec.tsx	✅ Passed (Inspect)	1m 17s	18	0	0
formBuilder/inputs/PortableText/PresenceCursors.spec.tsx	✅ Passed (Inspect)	9s	3	9	0
formBuilder/inputs/PortableText/RangeDecoration.spec.tsx	✅ Passed (Inspect)	26s	9	0	0
formBuilder/inputs/PortableText/Styles.spec.tsx	✅ Passed (Inspect)	18s	6	0	0
formBuilder/inputs/PortableText/Toolbar.spec.tsx	✅ Passed (Inspect)	37s	12	0	0
formBuilder/tree-editing/TreeEditing.spec.tsx	✅ Passed (Inspect)	0s	0	3	0
formBuilder/tree-editing/TreeEditingNestedObjects.spec.tsx	✅ Passed (Inspect)	0s	0	3	0

[RitaDias]

I'm not sure if you've raised this somewhere else or where do we want to keep this information so it doesn't get lost, but I feel it's something that should be prioritised to do? :) And since you've already gone through the issue of compiling this list, it makes sense to not lose it!

I wouldn't worry about it too much. For function components you'll see the ones we need to refactor by running pnpm check:react-compiler, and you see them on PRs showing up like this (although GitHub caps the list at 10, so it's not showing all 80 warnings): That was my starting point for creating the list, and if anything should be prioritised I'd say it's to get those warnings down to zero and then we can re-assess what to do next :)

Forgive me if this doesn't make sense, a question: is there a world where wouldn't want this by default? I think we are now adding it as a property that users can turn on but it feels like an overall useful thing to provide with the studio? Or perhaps there are some caveats / DX things that I am not seeing? Or maybe it's because it's still in beta and not fully out yet? 😅

The guidance from the core team is to keep it as opt-in until it reaches stable 😮‍💨

This makes sense :) thank you for answering it 🙏

[rexxars]

I agree with your suggestions for CLI improvements - I will see if we can make at least some of those changes available in follow-up PR(s) shortly. For now, documenting ("publicly") how to enable the React compiler and which dependencies to install would be a good first step.

[stipsan]

I agree with your suggestions for CLI improvements - I will see if we can make at least some of those changes available in follow-up PR(s) shortly. For now, documenting ("publicly") how to enable the React compiler and which dependencies to install would be a good first step.

Sure @rexxars, I'll get right on that, similar to the react 19 docs page 🙌