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.

Sign up for GitHub

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

Jump to bottom

Fix additional types for React 18 #7161

Merged
merged 5 commits into from
Jan 14, 2025
Merged

Fix additional types for React 18 #7161

merged 5 commits into from
Jan 14, 2025

Conversation

ggdouglas
Copy link
Contributor

@ggdouglas ggdouglas commented Jan 14, 2025 •
edited
Loading

Cherry-picked from React 18 Upgrade feature branch #7142

Fixes some additional remaining type compile breaks in anticipation of internal React 18 upgrade.

@changelog-app
Copy link

changelog-app bot commented Jan 14, 2025

Generate changelog in packages/core/changelog/@unreleased

What do the change types mean?
  • feature: A new feature of the service.
  • improvement: An incremental improvement in the functionality or operation of the service.
  • fix: Remedies the incorrect behaviour of a component of the service in a backwards-compatible way.
  • break: Has the potential to break consumers of this service's API, inclusive of both Palantir services
    and external consumers of the service's API (e.g. customer-written software or integrations).
  • deprecation: Advertises the intention to remove service functionality without any change to the
    operation of the service itself.
  • manualTask: Requires the possibility of manual intervention (running a script, eyeballing configuration,
    performing database surgery, ...) at the time of upgrade for it to succeed.
  • migration: A fully automatic upgrade migration task with no engineer input required.

Note: only one type should be chosen.

How are new versions calculated?
  • ❗The break and manual task changelog types will result in a major release!
  • 🐛 The fix changelog type will result in a minor release in most cases, and a patch release version for patch branches. This behaviour is configurable in autorelease.
  • ✨ All others will result in a minor version release.

Type

  • Feature
  • Improvement
  • Fix
  • Break
  • Deprecation
  • Manual task
  • Migration

Description

Fix additional types for React 18

Generate changelog in packages/table/changelog/@unreleased

What do the change types mean?
  • feature: A new feature of the service.
  • improvement: An incremental improvement in the functionality or operation of the service.
  • fix: Remedies the incorrect behaviour of a component of the service in a backwards-compatible way.
  • break: Has the potential to break consumers of this service's API, inclusive of both Palantir services
    and external consumers of the service's API (e.g. customer-written software or integrations).
  • deprecation: Advertises the intention to remove service functionality without any change to the
    operation of the service itself.
  • manualTask: Requires the possibility of manual intervention (running a script, eyeballing configuration,
    performing database surgery, ...) at the time of upgrade for it to succeed.
  • migration: A fully automatic upgrade migration task with no engineer input required.

Note: only one type should be chosen.

How are new versions calculated?
  • ❗The break and manual task changelog types will result in a major release!
  • 🐛 The fix changelog type will result in a minor release in most cases, and a patch release version for patch branches. This behaviour is configurable in autorelease.
  • ✨ All others will result in a minor version release.

Type

  • Feature
  • Improvement
  • Fix
  • Break
  • Deprecation
  • Manual task
  • Migration

Description

Fix additional types for React 18

Check the box to generate changelog(s)

  • Generate changelog entry

@svc-palantir-github
Copy link

Replace ResizeHandle with React.JSX.Element in resizableTest

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

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

jscheiny
jscheiny reviewed Jan 14, 2025
View reviewed changes
packages/core/test/overflow-list/overflowListTests.tsx
@@ -238,7 +238,7 @@ describe("<OverflowList>", function (this) {

/** Assert ordered IDs of overflow items. */
wrapper.assertOverflowItems = (...ids: number[]) => {
const overflowItems = wrapper.find(TestOverflow).prop("items");
const overflowItems: TestItemProps[] = wrapper.find(TestOverflow).prop("items");
Copy link
Contributor

Choose a reason for hiding this comment

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

Out of curiosity, what is the default type here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

On develop, the default type is inferred as TestItemProps[] (as the code would lead you to expect).

However, in the React 18 upgrade branch, the type for overflowItems evaluates to any. I'm assuming this is an issue with the React 18 enzyme wrapper that we're using to support React 18 in these tests.

Screenshot 2025-01-14 at 14 39 49@2x

Screenshot 2025-01-14 at 14 40 10@2x

I'll add an inline code comment to reference this one.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

46d1e0d

packages/core/test/utils.ts Outdated
@@ -27,7 +27,9 @@ export function findInPortal<P>(overlay: ReactWrapper<P>, selector: string) {

// React 15: unstable_renderSubtree does not preserve tree so we must create new wrapper.
const portal = overlay.find(Portal).instance();
const portalChildren = new ReactWrapper(portal.props.children as React.JSX.Element[]);
const portalChildren = new ReactWrapper(
(portal as React.Component<PortalProps>).props.children as React.JSX.Element[],
Copy link
Contributor

Choose a reason for hiding this comment

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

If we're typing portal do we still need the cast for children?

Copy link
Contributor Author

@ggdouglas ggdouglas Jan 14, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

In this specific case, yes. Again, I think there is something odd going on with the types from the enzyme wrapper (or perhaps I'm limited in my own understanding)

Breaking this down:

  1. overlay.find(Portal).instance() returns React. Component<{}, {}, any>

Screenshot 2025-01-14 at 14 59 32@2x

  1. Since portal.props is of type Readonly<{}>, we get this error when trying to access children:

Screenshot 2025-01-14 at 15 03 30@2x

  1. Even when we cast portal to React.Component<PortalProps>, ReactWrapper still expects to be passed a nodes argument of type JSX.Element | JSX.Element[], which doesn't appear to be sympatico with the ReactNode type of children.

Screenshot 2025-01-14 at 15 06 00@2x

Perhaps we could keep the React.Component<PortalProps> cast and wrap children in a fragment to satisfy both the linter and enzyme?

const portal = overlay.find(Portal).instance() as React.Component<PortalProps>;
const portalChildren = new ReactWrapper(<>{portal.props.children}</>);

Copy link
Contributor Author

Choose a reason for hiding this comment

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

76161ca

@svc-palantir-github
Copy link

Use React fragment to make children type more compatible with enzyme

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 ad452b7 into develop Jan 14, 2025
12 of 15 checks passed
@ggdouglas ggdouglas deleted the feat/react-18-additional-type-and-compile-fixes branch January 14, 2025 20:49
@ggdouglas ggdouglas mentioned this pull request Jan 14, 2025
Merged
15 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jscheiny jscheiny jscheiny approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@ggdouglas @svc-palantir-github @jscheiny