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

Update types and props for compatibility with React 18 #7150

Merged
merged 17 commits into from
Jan 11, 2025

Conversation

ggdouglas
Copy link
Contributor

@ggdouglas ggdouglas commented Jan 10, 2025

Copied from React 18 Upgrade feature branch #7142

Proposed changes:

Updates types for forward compatibility with React 18.

@ggdouglas ggdouglas mentioned this pull request Jan 10, 2025
15 tasks
gluxon
gluxon previously approved these changes Jan 10, 2025
packages/core/src/components/entity-title/entityTitle.tsx Outdated Show resolved Hide resolved
@@ -24,7 +24,7 @@ import { H4 } from "../html/html";

import { Hotkey, type HotkeyProps } from "./hotkey";

export interface HotkeysProps extends Props {
export interface HotkeysProps extends Props, React.PropsWithChildren<object> {
Copy link
Contributor

Choose a reason for hiding this comment

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

It looks like we're expecting children to be React.ReactElement<HotkeyProps>. Should we use that type over object?

(child: React.ReactElement<HotkeyProps>) => child.props,

Or was the goal to preserve the same type definition of HotkeyProps and avoid compile breaks on consumers?

Copy link
Contributor

Choose a reason for hiding this comment

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

This one is a nitpick, but I've personally been avoiding React.PropsWithChildren<...> since I see the React docs usually write the children prop directly.

https://react.dev/learn/typescript#typing-children

Having the children prop directly in the interface also makes it easier to add a JSDoc on the field.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@@ -36,7 +36,7 @@ export interface ColumnWidths {
defaultColumnWidth: number;
}

export interface ColumnHeaderProps extends HeaderProps, ColumnWidths, ColumnIndices {
export interface ColumnHeaderProps extends React.PropsWithChildren<HeaderProps>, ColumnWidths, ColumnIndices {
Copy link
Contributor

Choose a reason for hiding this comment

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

nitpick: Similar comment around potentially writing the children field directly.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@palantir palantir deleted a comment from changelog-app bot Jan 10, 2025
@policy-bot policy-bot bot dismissed gluxon’s stale review January 10, 2025 18:35

Invalidated by push of 21a62fc

Fixing type error:
```
../table/src/cell/editableCell.tsx:198:17 - error TS2322: Type 'Element' is not assignable to type '(ReactElement<HotkeyProps, string | JSXElementConstructor<any>>[] & (boolean | ReactChild | ReactFragment | ReactPortal | null)) | undefined'.
  Type 'ReactElement<any, any>' is not assignable to type 'ReactElement<HotkeyProps, string | JSXElementConstructor<any>>[] & ReactPortal'.
    Type 'ReactElement<any, any>' is missing the following properties from type 'ReactElement<HotkeyProps, string | JSXElementConstructor<any>>[]': length, pop, push, concat, and 29 more.

198                 <Hotkey
                    ~~~~~~~
199                     key="edit-cell"
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
203                     onKeyDown={this.handleEdit}
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
204                 />
    ~~~~~~~~~~~~~~~~~~

  ../core/lib/esm/components/hotkeys/hotkeys.d.ts:17:5
    17     children?: Array<React.ReactElement<HotkeyProps>>;
           ~~~~~~~~
    The expected type comes from property 'children' which is declared here on type 'IntrinsicAttributes & IntrinsicClassAttributes<Hotkeys> & Pick<Readonly<HotkeysProps> & Readonly<...>, "className" | "children"> & InexactPartial<...> & InexactPartial<...>'

../table/src/table.tsx:504:25 - error TS2322: Type '(Element | Element[] | undefined)[]' is not assignable to type '(ReactElement<HotkeyProps, string | JSXElementConstructor<any>>[] & (boolean | ReactChild | ReactFragment | ReactPortal | null)) | undefined'.
  Type '(Element | Element[] | undefined)[]' is not assignable to type 'ReactElement<HotkeyProps, string | JSXElementConstructor<any>>[]'.
    Type 'Element | Element[] | undefined' is not assignable to type 'ReactElement<HotkeyProps, string | JSXElementConstructor<any>>'.
      Type 'undefined' is not assignable to type 'ReactElement<HotkeyProps, string | JSXElementConstructor<any>>'.

504         return <Hotkeys>{hotkeys.filter(element => element !== undefined)}</Hotkeys>;
                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  ../core/lib/esm/components/hotkeys/hotkeys.d.ts:17:5
    17     children?: Array<React.ReactElement<HotkeyProps>>;
           ~~~~~~~~
    The expected type comes from property 'children' which is declared here on type 'IntrinsicAttributes & IntrinsicClassAttributes<Hotkeys> & Pick<Readonly<HotkeysProps> & Readonly<...>, "className" | "children"> & InexactPartial<...> & InexactPartial<...>'
```
@ggdouglas ggdouglas requested a review from gluxon January 10, 2025 19:21
@svc-palantir-github
Copy link

Switch to React.ReactNode for HotkeysProps children declaration

Build artifact links for this commit: documentation | landing | table | demo

This is an automated comment from the deploy-preview CircleCI job.

@ggdouglas ggdouglas merged commit 9f1f1de into develop Jan 11, 2025
12 of 17 checks passed
@ggdouglas ggdouglas deleted the feat/react-18-compile-breaks branch January 11, 2025 01:38
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.

3 participants