-
Notifications
You must be signed in to change notification settings - Fork 435
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
base: next
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
2 Skipped Deployments
|
New and removed dependencies detected. Learn more about Socket for GitHub ↗︎
🚮 Removed packages: npm/@types/[email protected] |
No changes to documentation |
Component Testing Report Updated Jan 6, 2025 5:48 PM (UTC) ✅ All Tests Passed -- expand for details
|
⚡️ Editor Performance ReportUpdated Mon, 06 Jan 2025 17:51:10 GMT
Detailed information🏠 Reference resultThe performance result of
🧪 Experiment resultThe performance result of this branch
📚 Glossary
|
7de727d
to
b1092b1
Compare
b1092b1
to
ca1e5d2
Compare
ca1e5d2
to
d943448
Compare
d943448
to
81fd78a
Compare
81fd78a
to
7960b28
Compare
7960b28
to
735d7a1
Compare
735d7a1
to
904d9b7
Compare
904d9b7
to
baffa1b
Compare
47f994b
to
17f23c1
Compare
There was a problem hiding this 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> |
There was a problem hiding this comment.
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}, |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
'ref': (ref: InputRef) => { | ||
inputRef.current = ref | ||
}, |
There was a problem hiding this comment.
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)
)
'ref': (ref: InputRef) => { | ||
inputRef.current = ref | ||
}, |
There was a problem hiding this comment.
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
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 A good second step for us is to work through the |
17f23c1
to
e113d43
Compare
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.
Same, news to me too! Glad they're fixing it. |
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 tounknown
instead ofany
(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 ofimport {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:
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.