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

Open
wants to merge 1 commit into
base: next
Choose a base branch
from
Open

fix: React 19 typings (finally) #8171

wants to merge 1 commit into from

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

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/[email protected] None +1 439 kB
npm/@types/[email protected] None 0 5.75 kB types
npm/@types/[email protected] None 0 790 kB types

🚮 Removed packages: npm/@types/[email protected]

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 6, 2025 5:48 PM (UTC)

✅ All Tests Passed -- expand for details
File Status Duration Passed Skipped Failed
comments/CommentInput.spec.tsx ✅ Passed (Inspect) 1m 5s 15 0 0
formBuilder/ArrayInput.spec.tsx ✅ Passed (Inspect) 13s 3 0 0
formBuilder/inputs/PortableText/Annotations.spec.tsx ✅ Passed (Inspect) 39s 6 0 0
formBuilder/inputs/PortableText/copyPaste/CopyPaste.spec.tsx ✅ Passed (Inspect) 52s 11 7 0
formBuilder/inputs/PortableText/copyPaste/CopyPasteFields.spec.tsx ✅ Passed (Inspect) 0s 0 12 0
formBuilder/inputs/PortableText/Decorators.spec.tsx ✅ Passed (Inspect) 26s 6 0 0
formBuilder/inputs/PortableText/DisableFocusAndUnset.spec.tsx ✅ Passed (Inspect) 14s 3 0 0
formBuilder/inputs/PortableText/DragAndDrop.spec.tsx ✅ Passed (Inspect) 27s 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 26s 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 42s 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 Mon, 06 Jan 2025 17:51:10 GMT

Benchmark reference
latency of sanity@latest
experiment
latency of this branch
Δ (%)
latency difference
article (title) 23.5 efps (43ms) 26.3 efps (38ms) -5ms (-10.6%)
article (body) 50.5 efps (20ms) 50.8 efps (20ms) -0ms (-0.5%)
article (string inside object) 25.3 efps (40ms) 27.0 efps (37ms) -3ms (-6.3%)
article (string inside array) 22.2 efps (45ms) 24.4 efps (41ms) -4ms (-8.9%)
recipe (name) 40.0 efps (25ms) 47.6 efps (21ms) -4ms (-16.0%)
recipe (description) 44.4 efps (23ms) 52.6 efps (19ms) -4ms (-15.6%)
recipe (instructions) 99.9+ efps (7ms) 99.9+ efps (7ms) +0ms (-/-%)
synthetic (title) 17.9 efps (56ms) 18.5 efps (54ms) -2ms (-3.6%)
synthetic (string inside object) 18.5 efps (54ms) 20.0 efps (50ms) -4ms (-7.4%)

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) 43ms 65ms 80ms 498ms 905ms 11.6s
article (body) 20ms 25ms 45ms 92ms 260ms 6.1s
article (string inside object) 40ms 42ms 48ms 181ms 264ms 7.2s
article (string inside array) 45ms 47ms 49ms 150ms 222ms 7.0s
recipe (name) 25ms 26ms 31ms 47ms 3ms 7.8s
recipe (description) 23ms 24ms 25ms 38ms 0ms 5.0s
recipe (instructions) 7ms 9ms 12ms 25ms 0ms 3.4s
synthetic (title) 56ms 58ms 62ms 281ms 1087ms 14.2s
synthetic (string inside object) 54ms 56ms 61ms 262ms 1047ms 9.1s

🧪 Experiment result

The performance result of this branch

Benchmark latency p75 p90 p99 blocking time test duration
article (title) 38ms 61ms 64ms 478ms 881ms 10.7s
article (body) 20ms 23ms 31ms 211ms 305ms 6.1s
article (string inside object) 37ms 39ms 41ms 265ms 277ms 6.9s
article (string inside array) 41ms 43ms 46ms 155ms 164ms 6.8s
recipe (name) 21ms 23ms 25ms 37ms 0ms 6.9s
recipe (description) 19ms 20ms 22ms 38ms 0ms 4.8s
recipe (instructions) 7ms 8ms 9ms 20ms 0ms 3.2s
synthetic (title) 54ms 57ms 80ms 142ms 1535ms 13.1s
synthetic (string inside object) 50ms 52ms 55ms 126ms 632ms 8.0s

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

@stipsan stipsan enabled auto-merge January 3, 2025 16:28
@stipsan stipsan disabled auto-merge January 6, 2025 14:27
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.

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