Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: React 19 typings (finally) #8171

Merged
merged 1 commit into from
Jan 7, 2025
Merged

fix: React 19 typings (finally) #8171

merged 1 commit into from
Jan 7, 2025

Conversation

stipsan
Copy link
Member

@stipsan stipsan commented Jan 3, 2025

Description

This PR builds upon previous efforts to address React 19 upgrade issues but resolves additional gaps that persisted. While prior PRs applied necessary changes, they weren't sufficient to handle all TypeScript typing challenges introduced with React 19, particularly with ReactElement and scoped JSX.

Key highlights:

  • ReactElement Type Change:
    The ReactElement type now defaults to unknown instead of any (ReactElement changes). This change was a major source of TypeScript errors in schema definitions with custom components after upgrading to @types/react@19.

  • Scoped JSX Updates:
    Updated to use React.JSX.Element instead of import {type JSX} from 'react' to address compatibility issues with @sanity/tsdoc, which caused errors during ETL tasks (example issue). Testing confirmed this resolves the issue without introducing regressions.

  • React 19 marked as supported by the CLI
    When installing react 19 deps the sanity dev command no longer reports them as unsupported.

Most of the work in this PR were a direct result of running these commands:

npx types-react-codemod@latest preset-19 ./packages/sanity/src
npx types-react-codemod@latest preset-19 ./packages/@sanity/types/src
npx types-react-codemod@latest preset-19 ./packages/@sanity/vision/src

What to review

Anything not explained in the official guide has PR comments, please give them a look and let me know if any context is missing.

Testing

Since everything uses @types/react@19 our own CI tells us if the new types work. If we want to be extra thorough we might want to run a tagged release and see that react 18 typescript studios are able to upgrade without issues, and that failing react 19 ones now pass type checking.

Notes for release

React 19 typings are fully supported, TypeScript users can upgrade to @types/react@19 and be able to remove a bunch of // @ts-expect-error suppressions thanks to the improvements done by the React team 🎉

The CLI is now considering React 19 as fully supported, and no longer recommends downgrading to react 18. Keep an eye on https://arewereact19yet.sanity.build/ to see first party plugins status on their support, and soon it'll list popular third party plugins as well.

Copy link

vercel bot commented Jan 3, 2025

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 Jan 7, 2025 1:16pm
performance-studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jan 7, 2025 1:16pm
test-studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jan 7, 2025 1:16pm
2 Skipped Deployments
Name Status Preview Comments Updated (UTC)
studio-workshop ⬜️ Ignored (Inspect) Visit Preview Jan 7, 2025 1:16pm
test-next-studio ⬜️ Ignored (Inspect) Jan 7, 2025 1:16pm

Copy link

socket-security bot commented Jan 3, 2025

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

Package New capabilities Transitives Size Publisher
npm/@types/react-dom@19.0.2 None +1 439 kB
npm/@types/react-is@19.0.0 None 0 5.75 kB types
npm/@types/react@19.0.3 None 0 790 kB types

🚮 Removed packages: npm/@types/react-dom@18.3.5

View full report↗︎

Copy link
Contributor

github-actions bot commented Jan 3, 2025

No changes to documentation

Copy link
Contributor

github-actions bot commented Jan 3, 2025

Component Testing Report Updated Jan 7, 2025 1:19 PM (UTC)

✅ All Tests Passed -- expand for details
File Status Duration Passed Skipped Failed
comments/CommentInput.spec.tsx ✅ Passed (Inspect) 1m 3s 15 0 0
formBuilder/ArrayInput.spec.tsx ✅ Passed (Inspect) 12s 3 0 0
formBuilder/inputs/PortableText/Annotations.spec.tsx ✅ Passed (Inspect) 37s 6 0 0
formBuilder/inputs/PortableText/copyPaste/CopyPaste.spec.tsx ✅ Passed (Inspect) 51s 11 7 0
formBuilder/inputs/PortableText/copyPaste/CopyPasteFields.spec.tsx ✅ Passed (Inspect) 0s 0 12 0
formBuilder/inputs/PortableText/Decorators.spec.tsx ✅ Passed (Inspect) 25s 6 0 0
formBuilder/inputs/PortableText/DisableFocusAndUnset.spec.tsx ✅ Passed (Inspect) 14s 3 0 0
formBuilder/inputs/PortableText/DragAndDrop.spec.tsx ✅ Passed (Inspect) 26s 6 0 0
formBuilder/inputs/PortableText/FocusTracking.spec.tsx ✅ Passed (Inspect) 1m 7s 15 0 0
formBuilder/inputs/PortableText/Input.spec.tsx ✅ Passed (Inspect) 1m 28s 21 0 0
formBuilder/inputs/PortableText/ObjectBlock.spec.tsx ✅ Passed (Inspect) 1m 39s 18 0 0
formBuilder/inputs/PortableText/PresenceCursors.spec.tsx ✅ Passed (Inspect) 13s 3 9 0
formBuilder/inputs/PortableText/Styles.spec.tsx ✅ Passed (Inspect) 26s 6 0 0
formBuilder/inputs/PortableText/Toolbar.spec.tsx ✅ Passed (Inspect) 1m 43s 21 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

Copy link
Contributor

github-actions bot commented Jan 3, 2025

⚡️ Editor Performance Report

Updated Tue, 07 Jan 2025 13:21:44 GMT

Benchmark reference
latency of sanity@latest
experiment
latency of this branch
Δ (%)
latency difference
article (title) 21.7 efps (46ms) 25.0 efps (40ms) -6ms (-13.0%)
article (body) 53.5 efps (19ms) 48.1 efps (21ms) +2ms (+11.2%)
article (string inside object) 23.5 efps (43ms) 26.3 efps (38ms) -5ms (-10.6%)
article (string inside array) 21.7 efps (46ms) 23.3 efps (43ms) -3ms (-6.5%)
recipe (name) 40.0 efps (25ms) 46.5 efps (22ms) -4ms (-14.0%)
recipe (description) 45.5 efps (22ms) 55.6 efps (18ms) -4ms (-18.2%)
recipe (instructions) 99.9+ efps (7ms) 99.9+ efps (7ms) +0ms (-/-%)
synthetic (title) 18.5 efps (54ms) 20.2 efps (50ms) -5ms (-8.3%)
synthetic (string inside object) 18.9 efps (53ms) 19.2 efps (52ms) -1ms (-1.9%)

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) 46ms 75ms 101ms 555ms 1020ms 12.1s
article (body) 19ms 20ms 23ms 212ms 338ms 5.7s
article (string inside object) 43ms 45ms 61ms 92ms 249ms 7.3s
article (string inside array) 46ms 48ms 56ms 222ms 542ms 7.9s
recipe (name) 25ms 27ms 33ms 50ms 0ms 7.6s
recipe (description) 22ms 23ms 25ms 55ms 5ms 5.0s
recipe (instructions) 7ms 8ms 10ms 10ms 0ms 3.2s
synthetic (title) 54ms 57ms 64ms 263ms 1087ms 12.7s
synthetic (string inside object) 53ms 54ms 61ms 320ms 771ms 9.3s

🧪 Experiment result

The performance result of this branch

Benchmark latency p75 p90 p99 blocking time test duration
article (title) 40ms 64ms 69ms 379ms 756ms 11.6s
article (body) 21ms 24ms 34ms 110ms 257ms 6.0s
article (string inside object) 38ms 41ms 43ms 69ms 153ms 6.7s
article (string inside array) 43ms 46ms 53ms 125ms 340ms 7.1s
recipe (name) 22ms 23ms 25ms 48ms 0ms 7.5s
recipe (description) 18ms 20ms 21ms 30ms 0ms 4.5s
recipe (instructions) 7ms 9ms 10ms 11ms 0ms 3.2s
synthetic (title) 50ms 52ms 59ms 105ms 593ms 12.7s
synthetic (string inside object) 52ms 55ms 72ms 282ms 811ms 7.8s

📚 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.

Copy link
Member

@bjoerge bjoerge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Massive!

All looks good to me. I'm curious about the widespread usage of any for the props type of elements, e.g. ReactElement<any>. Would it not be better to keep them unknown?

@@ -55,7 +55,7 @@ export interface BaseSchemaTypeOptions {
export interface BaseSchemaDefinition {
name: string
title?: string
description?: string | ReactElement
description?: string | ReactElement<any>
Copy link
Member

@bjoerge bjoerge Jan 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be unknown instead of any?
(edit: I see you've answered this earlier)

@@ -19,8 +19,8 @@ interface PackageInfo {
// NOTE: when doing changes here, also remember to update versions in help docs at
// https://sanity.io/admin/structure/docs;helpArticle;upgrade-packages
const PACKAGES = [
{name: 'react', supported: ['^18'], deprecatedBelow: null},
{name: 'react-dom', supported: ['^18'], deprecatedBelow: null},
{name: 'react', supported: ['^18 || ^19'], deprecatedBelow: null},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

milestone!

@@ -47,7 +47,6 @@ export function UserComponentPane(props: UserComponentPaneProps) {
// NOTE: here we're utilizing the function form of refs so setting
// the ref causes a re-render for `UserComponentPaneHeader`
ref={setRef as any}
// @ts-expect-error - @TODO Fix typings
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

love to see these go away

Comment on lines +160 to +162
'ref': (ref: InputRef) => {
inputRef.current = ref
},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice

(I quite like using void for these: 'ref': (ref: InputRef) => void (inputRef.current = ref))

Comment on lines +160 to +162
'ref': (ref: InputRef) => {
inputRef.current = ref
},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, but I see we have the no-void eslint rule enabled. oh well

@stipsan
Copy link
Member Author

stipsan commented Jan 6, 2025

All looks good to me. I'm curious about the widespread usage of any for the props type of elements, e.g. ReactElement<any>. Would it not be better to keep them unknown?

I get where you're coming from :) My goal here is to unblock those on 19 first and foremost. Given the breakage is related to React.ReactElement changing from being implicitly any to unknown, it seems like the safest approach is to make all the 18 typings explicit, ensuring they are the same regardless of your react major.
For react 18 users nothing has changed, our published typings are literally the same as before. While for 19 we no longer get unexpected narrowing.

A good second step for us is to work through the any and find out which ones are safe to narrow down. I expect some will still have to be any, but certainly not all. Personally I also like the new honesty with the stricter implicit defaults. I had no idea that React.ReactElement where any by default, now it's obvious and I'm motivated to fix them 😄

@bjoerge
Copy link
Member

bjoerge commented Jan 7, 2025

I get where you're coming from :) My goal here is to unblock those on 19 first and foremost. Given the breakage is related to React.ReactElement changing from being implicitly any to unknown, it seems like the safest approach is to make all the 18 typings explicit, ensuring they are the same regardless of your react major.
For react 18 users nothing has changed, our published typings are literally the same as before. While for 19 we no longer get unexpected narrowing.

All good points. I agree it would be worse for everyone if we'd were to roll out such a massive breaking typing change in a minor of our own. Let's aim for changing to stricter types in our next major instead.

I had no idea that React.ReactElement where any by default, now it's obvious and I'm motivated to fix them 😄

Same, news to me too! Glad they're fixing it.

@stipsan
Copy link
Member Author

stipsan commented Jan 7, 2025

@bjoerge update, I just force pushed a migration from React.ReactElement over to React.JSX.Element.
Some more details here: sanity-io/ui#1555

Copy link
Member

@bjoerge bjoerge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Amazing work, @stipsan, ship it! ✨

@stipsan stipsan disabled auto-merge January 7, 2025 13:58
@stipsan stipsan merged commit 68f244b into next Jan 7, 2025
57 checks passed
@stipsan stipsan deleted the react-19-typings branch January 7, 2025 13:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants