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

UI: Remove use of React.FC in components #25588

Merged
merged 9 commits into from
Jan 25, 2024
Merged

Conversation

ShaunEvening
Copy link
Contributor

@ShaunEvening ShaunEvening commented Jan 12, 2024

What I did

In React 18, the React team removed the children typing from React.FC and is now best practice not to use it over all.

With that breaking change, a bunch of our component's types make them unusable with children as the types are incorrect or too narrow. This aims to resolve that.

  • Remove most use of React.FC from our component types
  • Make types for new Icon map better

Checklist for Contributors

Testing

The changes in this PR are covered in the following automated tests:

  • stories
  • unit tests
  • integration tests
  • end-to-end tests

Documentation

  • Add or update documentation reflecting your changes
  • If you are deprecating/removing a feature, make sure to update
    MIGRATION.MD

Checklist for Maintainers

  • When this PR is ready for testing, make sure to add ci:normal, ci:merged or ci:daily GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found in code/lib/cli/src/sandbox-templates.ts

  • Make sure this PR contains one of the labels below:

    Available labels
    • bug: Internal changes that fixes incorrect behavior.
    • maintenance: User-facing maintenance tasks.
    • dependencies: Upgrading (sometimes downgrading) dependencies.
    • build: Internal-facing build tooling & test updates. Will not show up in release changelog.
    • cleanup: Minor cleanup style change. Will not show up in release changelog.
    • documentation: Documentation only changes. Will not show up in release changelog.
    • feature request: Introducing a new feature.
    • BREAKING CHANGE: Changes that break compatibility in some way with current major version.
    • other: Changes that don't fit in the above categories.

🦋 Canary release

This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the @storybookjs/core team here.

core team members can create a canary release here or locally with gh workflow run --repo storybookjs/storybook canary-release-pr.yml --field pr=<PR_NUMBER>

@@ -207,7 +207,7 @@ type TextareaProps = Omit<
valid?: ValidationStates;
height?: number;
} & React.RefAttributes<HTMLTextAreaElement>;
export const Textarea: FC<TextareaProps> = Object.assign(
export const Textarea = Object.assign(
styled(
forwardRef<any, TextareaProps>(function Textarea({ size, valid, align, ...props }, ref) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is children included somewhere in TextareaProps? I didn't see it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No but it shouldn't need it anyway for an input Element, right?

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, the name threw me. I thought it was rendering a <textarea>.

Copy link
Contributor

Choose a reason for hiding this comment

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

Indeed, it is:

type TextareaPropsRaw = React.TextareaHTMLAttributes<HTMLTextAreaElement>;

Copy link
Contributor

Choose a reason for hiding this comment

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

@kylegach I don't think passing children to this Textarea is valid anyway, so it seems like this fixes a type bug, removing that possibility?

Copy link
Contributor

@kylegach kylegach left a comment

Choose a reason for hiding this comment

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

Not sure about the comprehensiveness here (i.e. if there are other instances to address), but the refactors I see here look great!

@ShaunEvening
Copy link
Contributor Author

@kylegach in the components package there's only the tabs component remaining because it does some children manipulation with pretty hairy types.

We should refactor that separately or deprecate it for an easier API

@vanessayuenn vanessayuenn added this to the 8.0-beta milestone Jan 15, 2024
@kylegach kylegach self-assigned this Jan 23, 2024
@JReinhold JReinhold merged commit ca8da84 into next Jan 25, 2024
54 of 58 checks passed
@JReinhold JReinhold deleted the shaun/component-types branch January 25, 2024 11:50
@github-actions github-actions bot mentioned this pull request Jan 25, 2024
11 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants