Migrate components default props usage

[CarlosCortizasCT]

Summary

This PRs migrated the way we use defaultProps in React components as a preparation step to the upcoming overall migration from React v17 to React v19.

We're using a codemod published from app-kit (reference) in order to automate the process as much as possible.

Description

The way we are using React components defaultProps in our codebase is no longer supported in the new React 19 version (reference).

This is the main concept:

// BEFORE
type TMyComponentProps = {
  prop1: string;
  prop2: string;
  prop3: string;
};

function MyComponent(props: TMyComponentProps) {
  return (
    <ul>
    <li>Prop 1: {props.prop1}</li>
    <li>Prop 2: {props.prop2}</li>
    <li>Prop 3: {props.prop3}</li>
  </ul>
  );
}
MyComponent.defaultProps = {
  prop1: 'My default value',
};


// AFTER
type TMyComponentProps = {
  prop1?: string; // <--- Make sure this is marked as optional
  prop2: string;
  prop3: string;
};

function MyComponent({ prop1: 'My default value', ...props }: TMyComponentProps) { // <--- default values here
  return (
    <ul>
    <li>Prop 1: {prop1}</li> {* <--- Direct access to destructured property *}
    <li>Prop 2: {props.prop2}</li>
    <li>Prop 3: {props.prop3}</li>
  </ul>
  );
}
// <--- No "defaultProps" component property

NOTES

Something to bear in mind about the new pattern for using default props is that those props are not computed until the component is renderer whereas the legacy pattern make them available even before.
This has been discovered while migrating the RadioGroup and PrimaryActionDropdown components where we are inspecting the received children before rendering.

Here is a code example:

const optionElements = Children.map(props.children, (child, index) => {
    // NOTE: Allowing to intersperse other elements than `Option`.
    if (
      child &&
      isValidElement(child) &&
      (child as TReactChild).type.displayName === Option.displayName
    ) {
      const clonedChild = cloneElement(child as TReactChild, { ... });
      const { wrapper } = child.props.components; // <---- HERE WE ARE ACCESSING A CHILD COMPONENT PROPERTY
      return wrapper ? wrapper(clonedChild) : clonedChild;
    }
    return child;
  });

When using the legacy defaultProps property, the props of the child included the components prop as it was a default value (empty object).
With the new pattern (the default value is in the component function declaration), the props of the child at this point does not include that property.

[changeset-bot]

⚠️ No Changeset found

Latest commit: d8208de

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
ui-kit	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 18, 2024 5:47pm

[ByronDWall]

Is this file something that should be ignored/removed?

[CarlosCortizasCT]

Sorry. That was a mistake.

I removed those files.

[ddouglasz]

builds fine, and just the class components still have defaultProps. Looks good to me 💯
Thank you!

[ByronDWall]

Overall looks good. just out of curiosity, what percentage of this was completed by the codemod?

[CarlosCortizasCT]

Overall looks good. just out of curiosity, what percentage of this was completed by the codemod?

@ByronDWall That's a good question but does not have a direct answer.

The codemod refactored around 60 files.
After the first iteration, I would say I had to adjust between 8 and 10 files. Those were adjustments on top of what the codemod already had done.
Some of the manual adjustments have been incorporated to the codemod as a follow-up but there were some with very specific use cases I don't see trying to implement them in it.

The goal is for the codemod to cover the majority of a codebase, but not getting to a 100% coverage as that would take too much effort.