This is my snapshot v4.4.3 vs 4.5.0
In class name, we have duplicated item


| Tech | Version |
| ----------- | ------- |
| Material-UI | v4.5.0 |
| React |v16.10.1 |
| Browser |Chrome |
| TypeScript | no |
| etc. | |
I believe it originates here (from #17529): https://github.com/mui-org/material-ui/blob/7a5f830b5b5be9554a60f2fa4d03ec969b145dbe/packages/material-ui/src/Button/Button.js#L275
We must rollback to v4.4.3?
If it's causing you a problem, then yes, until it gets fixed.
Does it mean we should go for?
diff --git a/packages/material-ui/src/Button/Button.js b/packages/material-ui/src/Button/Button.js
index daf666872..7ef8e42d8 100644
--- a/packages/material-ui/src/Button/Button.js
+++ b/packages/material-ui/src/Button/Button.js
@@ -272,8 +272,8 @@ const Button = React.forwardRef(function Button(props, ref) {
className={clsx(
classes.root,
classes[variant],
- classes[`${variant}${color !== 'default' && color !== 'inherit' ? capitalize(color) : ''}`],
{
+ [classes[`${variant}${capitalize(color)}`]]: color !== 'default' && color !== 'inherit',
[classes[`${variant}Size${capitalize(size)}`]]: size !== 'medium',
[classes[`size${capitalize(size)}`]]: size !== 'medium',
[classes.disabled]: disabled,
I can take this
@netochaves sure :)
Why mix two variants of clsx arguments, why not just stick to one:
classes.root,
classes[variant],
{
[classes[`${variant}${capitalize(color)}`]]: color !== 'default' && color !== 'inherit',
[classes[`${variant}Size${capitalize(size)}`]]: size !== 'medium',
[classes[`size${capitalize(size)}`]]: size !== 'medium',
[classes.disabled]: disabled,
[classes.fullWidth]: fullWidth,
[classes.colorInherit]: color === 'inherit',
},
className,
vs
classes.root,
classes[variant],
color !== 'default' && color !== 'inherit' && classes[`${variant}${capitalize(color)}`],
size !== 'medium' && classes[`${variant}Size${capitalize(size)}`],
size !== 'medium' && classes[`size${capitalize(size)}`],
disabled && classes.disabled ,
fullWidth && classes.fullWidth ,
color === 'inherit' && classes.colorInherit,
className,
@croraf Is because 99% of the codebase already uses this approach a good answer? Alternatively, compare the readability of the two provided examples.
@oliviertassinari For me, more readable is the second one, as it is consistent. I'm not clear of what is the convention we follow when we put something in the object vs something as a plain argument?
Most helpful comment
I can take this