I’m looking for advice around #material-ui/core in react,
TLDR;
I would appreciate a consistent approach for handling CSS-in-js generated classNames which have indeterminate numeric suffixes, while still using #material-ui/core's styled() function if possible.
Specifically
“the class names generated by #material-ui/core/styles are non-deterministic” (https://material-ui.com/styles/advanced/#class-names), but so far at my company the projects I’ve been on have used the styled() function for wrapping components to apply styles.
It works great, until I want to overwrite how one of the pseudo-classes applies to the root element that I’m styling. At which point, if I try to use a regular old class-selector to take control of the styling in ta specific state, it’ll work if there’s no suffix on the class, but as soon as the JSS generated className has a numeric suffix, it breaks.
When I say "suffix" I'm referring to how a component's root className might be .makeStyles-root but when the className is generated for that specific instance, it likely has a numeric suffix appended: .makeStyles-root-123
For example:
Component: InputLabel https://material-ui.com/api/input-label/#inputlabel-api
I want to fiddle with the transform that happens, which comes from .MuiInputLabel-formControl, but then that transform is overwritten by .MuiInputLabel-shrink.
If I try using a regular class selector:
export const InputLabel = styled(MuiInputLabel)({
`&.MuiInputLabel-formControl`: {
transform: 'translate(2px, 8px) scale(1)',
},
`&.MuiInputLabel-shrink`: {
transform: 'translate(0) scale(0.6)',
},
});
It works only if the JSS class doesn’t have a suffix,
and if I try using the rule names (I don’t think it’s actually supported with styled())
export const InputLabel = styled(MuiInputLabel)({
formControl: {
transform: 'translate(2px, 8px) scale(1)',
},
shrink: {
transform: 'translate(0) scale(0.6)',
},
});
It just applies invalid rules to the element:
formControl: [object Object]
shrink: [object Object];
I've also tried passing classes (but that didn't seem to work at all)
export const InputLabel = styled((props) => (
<MuiInputLabel
classes={{
formControl: {
transform: 'translate(2px, 8px) scale(1)',
},
shrink: {
transform: 'translate(0) scale(0.6)',
},
}}
{...props}
/>
))({});
Further Notes
I don’t want to use a theme override (which I imagine would enable the use of those rules here) because I don’t want this styling to apply to all instances of a InputLabel
so that leaves me leaning towards using the hook api / makeStyles() : https://material-ui.com/styles/basics/#hook-api
But that doesn’t lend itself well to current patterns with style files.
Related
I've seen these similar questions:
jss to override a material-ui nondeterministic class
How override material ui style with hooks
the difference is that I'm trying to avoid using the hook api if possible.
As far as I can tell, it isn't possible to do this with styled(),
so I've just gone with what other posts have suggested and used makeStyles().
However I have used a bit of a mash-up of the two, so that I can still keep my styling in a separate file.
const useLabelStyles = makeStyles((theme) => ({
root: {
color: theme.text.primary,
},
formControl: {
transform: 'translate(2px, 8px) scale(1)',
},
shrink: {
transform: 'translate(0) scale(0.6)',
},
}));
export const InputLabel = styled((props) => {
const theme = useTheme();
const classes = useLabelStyles(theme);
return (
<MuiInputLabel
classes={classes}
{...props}
/>
);
})({});
Related
I am using MUI v5 together with Quill in React.
I can pass a className prop to the ReactQuill component and change it's styling:
const useStyles = makeStyles((theme) => ({
editor: {
'& .ql-editor': {
border: 'none',
// and so on...
}
}
}))
<ReactQuill className={classes.editor} ... />
Now with MUIv5 and its migration to emotion, this is not possible anymore. My workaround currently is to wrap the ReactQuill element inside a div like so:
const ReactQuillContainer = styled('div')(({theme}) => ({
'& .ql-editor': {
border: 'none',
// and so on...
}
}))
<ReactQuillContainer>
<ReactQuill ... />
</ReactQuillContainer>
But this changes the underlying DOM structure.
Is there a way to achieve the old result in the new way? I know about the css function, however I need the theme for styling and I don't think that is possible.
I also don't want to inline all those styles.
Have you solved this yet? I'm facing a similar issue, where I'd like to programmatically set MUI TextField styling on a Quill editor.
If not, have you tried passing Quill itself to styled? This works for me, though it doesn't solve my core problem. I'm also not sure it will allow you to set styles on child classes, but that may not be an issue.
const StyledQuill = styled(ReactQuill)(({ theme }) => ({
color: theme.palette.warning.main,
// and so on...
}));
I have an issue where I render lots of components, where each of these components have a useStyles. We want the components props to affect the styling, so we combine props and theme settings. Works fine, except that it's incredible slow and I have narrowed it down to it being caused by having prop methods in makeStyles.
It actually doesn't matter if the class is used or not. If all classes are static it's fast, but if I add an unused class that is a method it's slow. The prop doesn't matter either, like if I add test: { fontWeight: () => 'bold' } it's going to be slow again.
Very weird indeed. I'm using Material UI ^4.11.0. Not the latest version of v4. Bug? Anyone heard of this? Anyone got a better solution for adding prop based styles and using the theme at the same time? Anyone got a performance improvement by using useMemo or anything? (It had not effect when I tried).
const useStyles = makeStyles(({ typography }) => ({
fontFamily: {
fontFamily: ({ fontFamily }: any) => fontFamily,
},
fontFamilySecondary: {
fontFamily: typography.fontFamilySecondary,
},
...filterCustomVariants(typography),
bold: {
fontWeight: typography.fontWeightBold,
},
boldScondary: {
fontWeight: typography.fontWeightBoldSecondary,
},
italic: {
fontStyle: "italic",
},
thisIsNotEvenUsed: {
fontWeight: () => {
console.log("Running running running") // Runs many times anyway!
return "bold"
},
},
}))
And the implementation:
const styleProps = { fontFamily: fontFamily }
const classes = useStyles(styleProps)
EDIT: Here are a CodeSandbox that shows this behavour, using latest MUI v4 and without my Apps complexity: https://codesandbox.io/s/black-monad-tr05l?file=/src/App.tsx
This is not a bug, makeStyles in v5 behaves the same way. The dynamic styles using callback is a JSS feature. But JSS dynamic performance has been known to be pretty terrible (see the performance section for more detail, it's about 6 times slower than emotion). That's one of the reason the MUI team decided to abandon it in favor of emotion in v5 which uses dynamic styles heavily.
And yes, it always invokes the callback even if you don't pass anything inside and don't make use of the classes object. It traverses the style object and invoke every callbacks it found when you call useStyles. For more detail about how makeStyles works, I recommend you reading this answer from Ryan.
const useStyles = makeStyles({
thisIsNotEvenUsed: {
fontWeight: () => {
console.log("Running running running"); // Runs many times anyway!
return "bold";
}
}
});
const unusedClasses = useStyles(); // generate the styles
There are some strategies to improve the performance. The easiest one (depend on the situation) is to upgrade to v5 to leverage emotion and its capability to generate dynamic styles efficiently. Another approach is to use the inline styles:
<Typography style={{ fontWeight: props.fontWeight }}>
But if you don't want to pollute your component with inline styles, you can still use makeStyles using the 'style injection' method by creating a nested styles in the container that holds a large amount of elements inside (Grid, List, Stack...)
const useStyles = makeStyles({
root: {
"& MuiTypography-root": {
fontWeight: () => 'bold'
}
}
});
<div className={classes.root}>
{[...Array(100)].map((_, index) => {
return <Text key={`text_${index}`}>Text Component</Text>;
})}
</div>
I need to override select component with border color to orange on error. Globally the outlined input bordercolor within my application is provided green. Only on error the border color has to overridden
import { FormControl, makeStyles, Select, withStyles } from '#material-ui/core';
const useStyles = makeStyles((theme) => ({
select: {
'&:before': {
borderColor: 'red',
},
'&:after': {
borderColor: 'red',
},
},
}));
const CustomSelect = ({
id,
value,
name,
variant,
onChange,
error,
priceType,
}) => {
const classes = useStyles();
return (
<FormControl size='small' error width='154px'>
<Select
id='price-type'
value={priceType}
native
name='priceType'
variant='outlined'
onChange={onChange}
error={true}
inputProps={{
style: {
width: '154px',
},
}}
className={classes.select}
>
<option value={''}></option>
<option value={'Retail'}>Retail</option>
<option value={'X-East'}>X-East</option>
</Select>
</FormControl>
);
};
export default CustomSelect;
General approach
Usually in MaterialUI when we want to override MaterialUI styles that are applied conditionally, we may use the classes prop:
classes={{ root: <class to apply always>, error: <class to apply in error state>}}
You can read about the CSS API and which classes are applicable for a given component at the bottom of its API page.
Alternatively, we can use a more elaborate approach and simply apply a rule whenever the component is in error state:
className={ error ? <class to apply in error state> : undefined }
The Select component
The Select component seems to be written at another time than most of the other MaterialUI input components. This is my intuitive impression based on API and code style but I might be wrong. Nevertheless, the Select component uses one of Input, FilledInput or OutlinedInput depending on the value of the variant property. Since you use outlined, I will continue this answer with OutlinedInput in mind. I will also use the color green for the border instead of orange because its distinction from red is more clear.
Naively, I would tackle the problem by looking at the CSS API of the Select component, and then also look closer at the OutlinedInput to which remaining properties of the Select component are spread. No applicable CSS API class exists on the Select component to reach your goal, but the OutlinedInput has a class error with the following description:
Pseudo-class applied to the root element if error={true}.
If we inspect the OutlinedInput in the development tools, we can see that the element that has the border is a fieldset residing inside the root element of the OutlinedInput (note: not the root element of the Select). If we use the error class, we will end up with an additional class applied to the root element of the OutlinedInput which is not what we want. Nonetheless, we could apply a class that refers to the aforementioned child element... this would work.
There is also a css class notchedOutline which we can see is applied to this fieldset resulting in the border. The dilemma here is that if we would be able to add some css to this class, then it would be applied at all times on the fieldset, but we want to apply it ONLY in error state.
This gives us four possible strategies to affect the css via the CSS API:
Add css conditionally (when in error) to the root class of the underlying OutlinedInput that targets child notchedOutline.
Add css to the root class of the underlying OutlinedInput that targets error state and child notchedOutline.
Add css to the error class of the underlying OutlinedInput and target child notchedOutline.
Add css conditionally (when in error) to the notchedOutline class of the underlying OutlinedInput.
Note that the second one and third are preferable in that they do not require us to add a class conditionally; this is handled by MaterialUI.
In the best of worlds, I would want the Select component to forward all of its non-existing props to the element it uses internally, in this case an OutlinedInput, but apparently, it does not forward portions of elements that it partially supports (the classes prop). This means that if we supply classes.error or classes.notchedOutline, MaterialUI will complain with
Material-UI: The key `XXXX` provided to the classes prop is not implemented in ForwardRef(Select).
instead of forwarding the prop to the underlying OutlinedInput. I do not know if this is a bug or not, but this is how it works currently.
This implies that we can not use any of the above four strategies via the classes prop of the Select component. A workaround is to use the Select className prop which is forwarded to the OutlinedInput which in turn forwards it to InputBase which forwards it to the native element, which is the same as the root element of the OutlinedInput. So, if we could access the underlying OutlinedInput itself, we could use all of the above strategies, otherwise only the first two (and then via className prop of the Select).
The solutions
1. Set the global error color of the entire app
If you want the error color to be something else than red for the entire app, then provide a theme which changes the color used for errors. This is the best approach since it also changes the color of helper texts and labels which would otherwise have a different color than the border of your Select input.
import green from '#material-ui/core/colors/green';
const theme = createTheme({
palette: {
error: {
main: green[500]
},
},
});
This is a clean and non-hacky way to do it and the one I recommend. However, if you DON'T want the general color for errors to be changed, this might not be a good solution, even though you could wrap just a local part of the app in a theme of its own.
2. Override the class used for notchedOutline in error state
This is a broad way to solve it since you can do this in several different ways using the four strategies described above. The downsides with all the solutions are that they are more or less hacky and that they only affect the border of the Select, implying that helper texts and labels will be differently colored than the border when the component is in error state (you could add styles to them too, making all of this very elaborate and hard to achieve).
2.a Global override / default for OutlinedInput
We can create a theme with a global override for the OutlinedInput. Since we then manipulate the OutlinedInput itself, we may use all four strategies from above.
Global override / default for OutlinedInput for root class targeting notchedOutline child
This theme would have to be applied conditionally only when the component is in error state. This is elaborate and not a good alternative.
Global override / default for OutlinedInput for root class targeting error state and notchedOutline child
const themeWithOverrides = createTheme({
overrides: {
MuiOutlinedInput: {
root: {
"&$error": {
"& $notchedOutline": {
border: "1px solid green"
}
}
}
}
}
})
This one works well and targets the OutlinedInput root class with css that applies only when it is in error state and applies to its notchedOutline child. The selectors refer to the css classes already defined by default in the theme for this component.
Global override / default for OutlinedInput for error class and notchedOutline child
const themeWithOverrides = createTheme({
overrides: {
MuiOutlinedInput: {
error: {
"& $notchedOutline": {
border: "1px solid green"
}
}
}
}
})
This solution results in an error message from MaterialUI
Material-UI: The `MuiOutlinedInput` component increases the CSS specificity of the `error` internal state.
which in turn recommends us to use the previous solution targeting the root class instead.
Global override / default for OutlinedInput for notchedOutline class
const themeWithOverrides = createTheme({
overrides: {
MuiOutlinedInput: {
notchedOutline: {
border: "1px solid green"
}
}
}
})
This will apply the style at all times which we don't want, so the theme has to be applied conditionally which is a hassle so this solution is not recommended at all.
2.b Css classes for Select component
Here we could also, in theory, use all of the four strategies described above. However, since we are not manipulating the OutlinedInput itself, and since MaterialUI doesn't forward the classes props that are not defined for the Select to the underlying component, only two remains.
Adding css class conditionally to className prop of the Select which is applied to the OutlinedInput root component targeting child notchedOutline
const useStyles = makeStyles((theme) => ({
errorState: {
"& .MuiOutlinedInput-notchedOutline": {
border: "1px solid green !important"
}
}
}))
...
<Select
...
className={ errorFlag ? classes.errorState : undefined }
...
</Select>
This solution both uses literal MaterialUI css classes and requires us to conditionally add the class. Finally, we have to use the !important modifier to override the specificity of the MaterialUI default behaviour. All in all, this has a slightly hacky flavour to it.
Adding css class to className prop of the Select which is applied to the OutlinedInput root component targeting child notchedOutline only in error state
const useStyles = makeStyles((theme) => ({
errorState: {
"&.Mui-error": {
"& .MuiOutlinedInput-notchedOutline": {
border: "1px solid green"
}
}
}
}))
...
<Select
...
className={ classes.errorState }
...
</Select>
This is slightly better because we don't need to conditionally apply the style. Also, as long as this style is injected after the MaterialUI default style, we can omit the !important modifier since this rule achieves the same specificity as the MaterialUI default behaviour. This method is absolutely preferable over the previous.
2.c Css classes for underlying OutlinedInput component via input prop on Select
The Select component takes a prop input which lets you define your own input components to be used. Here we can use a custom component that returns an OutlinedInput with the modifications you want.
export default function CustomInput(props) {
return (
<OutlinedInput
{...props}
<CHANGES HERE>
/>
)
}
Since we here can work directly towards the OutlinedInput, we can use its CSS API and thus use all the four strategies described earlier.
Note that to do it by the book, you should merge incoming classes.error and classes.notchedOutline with the classes you assign by default as well.
Adding css class conditionally to classes.root prop targeting child notchedOutline
Since we now have access to the classes.error prop, providing this class conditionally would not be a smart option.
Adding css class to classes.root prop targeting state error and child notchedOutline
Similarly, since we now have access to the classes.error prop, providing a class here targeting error state instead of targeting it directly would be an extra workaround and is not recommended.
Adding css class to classes.error prop targeting child notchedOutline
const useStyles = makeStyles((theme) => ({
error: {
"& .MuiOutlinedInput-notchedOutline": {
border: "1px solid green !important"
}
}
}))
export default function CustomInput(props) {
const classes = useStyles()
return (
<OutlinedInput
{...props}
classes={{ ...props.classes, error: classes.error }}
/>
)
}
This is a good alternative that allows us to leave the decision of whether the component is in error state or not to MaterialUI. Slightly hacky to use the literal MaterialUI css classes and that we have to provide the !important flag to override the higher specificity of the MaterialUI default behaviour.
Adding css class conditionally to classes.notchedOutline prop when in error state
const useStyles = makeStyles((theme) => ({
errorOutline: {
border: "1px solid green !important"
}
}))
export default function CustomInput(props) {
const classes = useStyles()
return (
<OutlinedInput
{...props}
classes={{ ...props.classes, notchedOutline: errorFlag ? classes.errorOutline : undefined }}
/>
)
}
This is equally good as the previous. It saves us from using literal
MaterialUI css classes but it forces us to add the class conditionally. Also here we have to provide the !important flag to override the higher specificity of the MaterialUI default behaviour.
Conclusion
It's a shame that it seems to be quite complicated to change such a simple thing. Nonetheless, the best solutions seem to be:
Use global error color override if you want to have a robust solution with uniform appearence for all inputs in your app that harmonize with labels and helper texts.
import green from '#material-ui/core/colors/green';
const theme = createTheme({
palette: {
error: {
main: green[500]
},
},
})
Use global override for OutlinedInput if you want a uniform error color across all OutlinedInputs and if you're ok with labels and helper texts that don't harmonize.
const themeWithOverrides = createTheme({
overrides: {
MuiOutlinedInput: {
root: {
"&$error": {
"& $notchedOutline": {
border: "1px solid green"
}
}
}
}
}
})
Use a custom input which conditionally overrides the classes.notchedOutline when the component is in error state if you need a one-time change on a single or couple of Selects / OutlinedInputs and if you can accept labels and helper texts that don't harmonize in color. I prefer this solution because I don't like to use literal MaterialUI css classes in my code.
const useStyles = makeStyles((theme) => ({
errorOutline: {
border: "1px solid green !important"
}
}))
export default function CustomInput(props) {
const classes = useStyles()
return (
<OutlinedInput
{...props}
classes={{ ...props.classes, notchedOutline: errorFlag ? classes.errorOutline : undefined }}
/>
)
}
...
<Select input={<CustomInput error={errorFlag} />} />
...
Here is a code sandbox with some of these recommended examples
You can use this styles
const useStyles = makeStyles((theme) => ({
select: {
borderColor:'#f00',
'&:focus': {
borderColor: '#f00',
},
},
}));
In the Material UI documents, they provided sample code to show how one can change the color of a Radiobutton.
const GreenRadio = withStyles({
root: {
color: green[400],
'&$checked': {
color: green[600],
},
},
checked: {},
})(props => <Radio color="default" {...props} />);
I would like to replicate this with styled-component instead i.e. const StyledRadio = styled(Radio) but I am not too familiar with the syntax such as the ampersand and the dollar sign - how can I do this?
When using styled components with MUI, the CSS is applied to the root class of the component. If you need to apply a more specific style, then you'll need to target the relevant class. In this case, you'll need to target the .Mui-checked class:
const StyledRadio = styled(Radio)`
color: ${green[400]};
&.Mui-checked {
color: ${green[600]};
}
`;
The MUI docs are really good in that they list the CSS classnames for each component. If you visit the API docs for the Radio component, you'll see the .Mui-checked class listed there (under the 'Global Styles' column).
Here's a working example in Code Sandbox: https://codesandbox.io/embed/styled-components-9pewl
Here's the appropriate styled-components syntax:
const GreenRadio = styled(Radio)`
color: ${green[400]};
&.Mui-checked {
color: ${green[600]};
}
`;
Related documentation: https://material-ui.com/customization/components/#pseudo-classes
So, whenever I use withStyles, it creates a default prop named - (this.props.{classes}) and if I use withTheme it creates -(this.props.{theme}).
Question 1
theme prop here does it contain theme data related to the MaterialUI Components I am using or just theme data for all components?
Question 2
My 2nd Question is, what if I want to store these props into a single object such as *this.props.header.classes and this.props.header.theme*. Is it possible to do this?
Question 3
My 3rd question is, How are the class names defined internally? According to me, they might be using some library like classnames or clsx. Am I stating correct?
Example
Here is the classname which was created for a component appBar - App-appBar-2
I think appBar because that is the name of style key in the styles object.
Does the number 2 here has any significance?
Here is the snippet of styles
const headerStyles = theme => ({
root: {
display: "flex"
},
appBar: {
zIndex: theme.zIndex.drawer + 1,
transition: theme.transitions.create(["width", "margin"], {
easing: theme.transitions.easing.sharp,
duration: theme.transitions.duration.leavingScreen
})
},
...
...
)}
What I have -
props = {
classes,
theme,
...
}
What I plan to have is -
props = {
header: {
classNames: classes,
theme: theme
},
...
}
Any help is appreciated.
Answer 1: it's the whole theme provided by your theme provider upstream.
Answer 2: That would be only possible by using a second higher order Component (not recommend), which wraps it's props into seperated header props.
Answer 3: The class name composition is mentioned in the docs
Hope this helps. Happy coding.