-
-
Notifications
You must be signed in to change notification settings - Fork 32.4k
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
[material] Add variant
prop type in all components
#33510
Comments
The |
Isn't that because the API docs are generated from typings? So there would be an issue in API also because an existing prop is missing from the docs. Though it wouldn't be nice to have it in the API docs since there seems to be no ready-made variants for it by default 🤔 But now the typings are blocking everyone from using the prop... |
I started to work on a PR for this. |
@jussirantala Can you provide a CodeSandbox showing a |
Here you go: https://codesandbox.io/s/list-variant-bug-5fqdfp?file=/src/App.tsx |
Thanks for the reproduction. Looks like a bug indeed. Not sure how does the style ( Looks like this would be the case for many other components in general. |
Seems it also complains about missing |
Hi guys, I have similar issue with FormHelperText -> #33564 |
variant
prop is missing in typingsvariant
prop type in all components
Adding here some of the conversations we had on the open pull request. These are some open questions that would arise if we decide to support this in all components:
|
Hi @mnajdova, Wondering if there is any progress on this? We assumed variants to be supported in all component as mentioned in the docs. Our designer put time and effort in creating variants, now this does not seem to be supported. I would at least expect something like a notice in the docs, then we could have been aware of this months ago. |
Similar situation here, without the variant prop in List/ListItem/ListButtonItem, I am not able to implement my designer's variants the way we we implement new variants to other components like Button or Typography. |
Actually, I learned that you can add your own /* eslint-disable @typescript-eslint/no-empty-interface */
export type CustomListItemButtonOwnProps = {
variant?: "standard" | "condensed" | "comfort";
otherCustomProp?: boolean;
};
declare module "@mui/material/ListItemButton" {
interface ListItemButtonOwnProps extends CustomListItemButtonOwnProps {}
} or just declare module "@mui/material/ListItemButton" {
interface ListItemButtonOwnProps {
variant?: "standard" | "condensed" | "comfort";
otherCustomProp?: boolean;
}
} |
Yes you can extend the props or find other ways to create variants. But the variant functionality, so using variant in the theme, that is described in the docs of MUI, will not work. This means we have different ways of adding variants, which is not really desirable. |
Duplicates
Latest version
Current behavior 😯
Creating a List component variant causes TypeScript errors when using the
variant
prop in thevariants
declaration or at the component usage site.Suppressing the TypeScript errors allows the variant to be declared and used as expected.
Expected behavior 🤔
Creating a List component variant is supported in TypeScript.
ListProps
should have a declaration forvariant
, like we have inButtonProps
:Steps to reproduce 🕹
Steps:
CodeSandbox
Context 🔦
We're maintaining a UI library built on top of MUI, and we want to provide a "bordered" List variant for our users. This is is blocking us from doing that.
Your environment 🌎
No response
The text was updated successfully, but these errors were encountered: