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

[core] Adds component prop to OverrideProps type #35924

Merged
merged 24 commits into from Jul 18, 2023

Conversation

sai6855
Copy link
Contributor

@sai6855 sai6855 commented Jan 23, 2023

@sai6855 sai6855 marked this pull request as draft January 23, 2023 14:55
@sai6855 sai6855 changed the title [Core] Adds component type to OverrideProps [MenuItem] Adds component type to OverrideProps Jan 23, 2023
@mui-bot
Copy link

mui-bot commented Jan 23, 2023

Netlify deploy preview

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against 489d7b2

@sai6855 sai6855 changed the title [MenuItem] Adds component type to OverrideProps [Core] Adds component type to OverrideProps Jan 23, 2023
@sai6855 sai6855 marked this pull request as ready for review January 24, 2023 17:31
@zannager zannager added the core Infrastructure work going on behind the scenes label Jan 25, 2023
Copy link
Member

@michaldudak michaldudak left a comment

Choose a reason for hiding this comment

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

As I understand it, the root cause of this problem is that we use the same type - OverrideProps for two things: to define the props of the component when a component prop is used (as in OverridableComponent) and to specify types of props in individual components (as type ButtonBaseProps<D, P> = OverrideProps<ButtonBaseTypeMap<P, D>, D>;).
Looking at the shape of the OverrideProps, only the first usage is correct, and ideally, we should use a different type for the props themselves.

However, the change you made fixes the problem of the second case and shouldn't affect the first case (because the OverrdableComponent's props become { component: C } & { component?: C } (plus other members), which is equivalent to { component: C }.

I can't think of every possible way developers use these types, so I can't predict how safe this change is. I think it should work fine, but I'm far from being sure. I'd appreciate a second reviewer's thoughts here.

@@ -33,7 +33,7 @@ const theme = createTheme({
MuiLink: {
defaultProps: {
component: LinkBehavior,
} as LinkProps,
} as unknown as LinkProps,
Copy link
Member

Choose a reason for hiding this comment

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

This is unfortunate. We shouldn't recommend such hacks, ideally, but I understand where it's coming from. Could ou try to work around it so such an ugly cast is not necessary?

Copy link
Contributor Author

@sai6855 sai6855 Apr 13, 2023

Choose a reason for hiding this comment

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

i've tried to remove as unknown type without disturbing other files but couldn't able to do it. So instead of fixing casting problem, tried to fix (commit 089f989 ) the root problem which lies in this file .

If you are fine with converting props in props.d.ts file to generic, i'll convert all components to generic where applicable. if not i'd appreciate your help fixing the casting issue.

Copy link
Member

Choose a reason for hiding this comment

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

I'd ask @mnajdova about the generic, as she's overseeing the styles. To me, it feels OK, but I have less context about the usage of these types.

Comment on lines 37 to 43
& {
/**
* The component used for the root node.
* Either a string to use a HTML element or a component.
*/
component?: C
}
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
& {
/**
* The component used for the root node.
* Either a string to use a HTML element or a component.
*/
component?: C
}
& {
/**
* The component used for the root node.
* Either a string to use a HTML element or a component.
*/
component?: C
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Resolved in this commit 132e413

Copy link
Member

Choose a reason for hiding this comment

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

All right, this looks good in general. Please merge in the latest mater, and I'll do the final review afterward.

@sai6855 sai6855 requested review from mnajdova and removed request for mnajdova April 13, 2023 16:06
@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label May 9, 2023
@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label May 12, 2023
@ZeeshanTamboli ZeeshanTamboli added the package: material-ui Specific to @mui/material label Jul 17, 2023
@ZeeshanTamboli ZeeshanTamboli changed the title [core] Adds component type to OverrideProps [core] Adds component prop to OverrideProps type Jul 17, 2023
Copy link
Member

@ZeeshanTamboli ZeeshanTamboli left a comment

Choose a reason for hiding this comment

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

I like it, but I didn't understand why this change had to be done. The tests give me confidence to proceed. Great job!

Copy link
Member

@DiegoAndai DiegoAndai left a comment

Choose a reason for hiding this comment

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

Hey @sai6855, thanks for working on this, and sorry for chiming in so late

I think @michaldudak and @ZeeshanTamboli approvals are enough to merge. Anyway, I also reviewed it and have some questions, if you could answer these before merging I would appreciate it.

PD: Regarding this comment: #35924 (review). I'll start a discussion with @mui/core about what we can do to improve it.

Copy link
Member

@DiegoAndai DiegoAndai left a comment

Choose a reason for hiding this comment

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

LGTM! 🚀

@DiegoAndai DiegoAndai merged commit 1b9c8ab into mui:master Jul 18, 2023
29 checks passed
@oliviertassinari
Copy link
Member

oliviertassinari commented Jul 18, 2023

So, we can remove this now?

props: {
/**
* The component used for the root node.
* Either a string to use a HTML element or a component.
*/
component: C;
} & OverrideProps<M, C>,

and

> = OverrideProps<BadgeTypeMap<{}, RootComponentType>, RootComponentType> & {
component?: RootComponentType;
};

and many more?

@sai6855
Copy link
Contributor Author

sai6855 commented Jul 19, 2023

= OverrideProps<BadgeTypeMap<{}, RootComponentType>, RootComponentType> & {
component?: RootComponentType;
};

base-ui uses OverrideProps from mui-types package. related file - https://github.com/mui/material-ui/blob/master/packages/mui-types/index.d.ts#L116

but this PR added component type to OverrideProps in this file https://github.com/mui/material-ui/blob/master/packages/mui-material/src/OverridableComponent.d.ts#L31

So i don't think above change is required.

@sai6855
Copy link
Contributor Author

sai6855 commented Jul 19, 2023

props: { 
   /** 
    * The component used for the root node. 
    * Either a string to use a HTML element or a component. 
    */ 
   component: C; 
 } & OverrideProps<M, C>, 

regarding removal of this code - i did a quick check and removed that type, but i can see typescript errors in few files. i'll have to dig deeper on why that's the case

@Methuselah96
Copy link
Contributor

Methuselah96 commented Jul 20, 2023

@sai6855 @michaldudak @oliviertassinari FYI, this made #34068 worse. Removing the { component: C } lines from the OverridableComponent type would help, but as @sai6855 noted, removing those lines would make the inference of parameters for callbacks not work for some reason.

sai6855 added a commit to sai6855/material-ui that referenced this pull request Jul 21, 2023
michaldudak added a commit to michaldudak/material-ui that referenced this pull request Jul 21, 2023
sai6855 added a commit to sai6855/material-ui that referenced this pull request Jul 24, 2023
@jocelynn1uphealth
Copy link

jocelynn1uphealth commented Jul 24, 2023

Hey MUI contributors @sai6855 @michaldudak @oliviertassinari! Thanks so much for all you do. This change is giving me new type errors when I pass a component prop into Card, a la <Card component="form">. The TypeError says I can only have "div" or undefined as values. Anything I should be doing differently in light of this change?

ETA: patch version 5.14.2 fixed this !

@sai6855
Copy link
Contributor Author

sai6855 commented Jul 24, 2023

Can you please share codesandbox link which reproduces the issue . Cc @jocelynn1uphealth

michaldudak added a commit to michaldudak/material-ui that referenced this pull request Jul 25, 2023
michaldudak pushed a commit to michaldudak/material-ui that referenced this pull request Jul 25, 2023
@jocelynn1uphealth
Copy link

@sai6855 the patch fix this morning fixed the issue, now it's working again. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 Something doesn't work core Infrastructure work going on behind the scenes package: material-ui Specific to @mui/material typescript
Projects
None yet