-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
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
[Slider] Replace core Slider with SliderStyled #23308
[Slider] Replace core Slider with SliderStyled #23308
Conversation
@material-ui/core: parsed: +1.29% , gzip: +1.47% |
@oliviertassinari & @eps1lon I would kindly ask you for final review, as I've addressed the last comment #23308 (comment) |
| <span class="prop-name">defaultValue</span> | <span class="prop-type">Array<number><br>| number</span> | | The default element value. Use when the component is not controlled. | | ||
| <span class="prop-name">disabled</span> | <span class="prop-type">bool</span> | <span class="prop-default">false</span> | If `true`, the slider is disabled. | | ||
| <span class="prop-name">disabled</span> | <span class="prop-type">bool</span> | | If `true`, the slider is disabled. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The defaults are now in the SliderUnstyled
, not here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have notices some aspects that require follow-ups, but that doesn't necessarily have to prevent merging this pull request.
| <span class="prop-name">min</span> | <span class="prop-type">number</span> | <span class="prop-default">0</span> | The minimum allowed value of the slider. Should not be equal to max. | | ||
| <span class="prop-name">isRtl</span> | <span class="prop-type">bool</span> | | Indicates whether the theme context has rtl direction. It is set automatically. | | ||
| <span class="prop-name">marks</span> | <span class="prop-type">Array<{ label?: node, value: number }><br>| bool</span> | | Marks indicate predetermined values to which the user can move the slider. If `true` the marks are spaced according the value of the `step` prop. If an array, it should contain objects with `value` and an optional `label` keys. | | ||
| <span class="prop-name">max</span> | <span class="prop-type">number</span> | | The maximum allowed value of the slider. Should not be equal to min. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Default values are missing. What do you think of "pulling" the values from SliderUnstyled?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me do that in a follow up PR as it will require again changes in the buildAPI, it would be easier to have it as a separate change. Will leave this open for visibility
left: 'calc(-50% + 12px)', | ||
top: -22, | ||
'& *': { | ||
background: 'transparent', | ||
color: '#000', | ||
}, | ||
}, | ||
track: { | ||
'& .MuiSlider-track': { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's going from "what name does this identifier have?" to
@eps1lon It will likely be simpler for most developers in v5. We have been regularly linking https://material-ui.com/styles/advanced/#with-material-ui-core in v4 when developers were struggling to understand how this classes
API work. It's not obvious for many. I think that the new syntax will work better because this it's closer to what developers are already familiar with: CSS/SASS. Another positive signal is the volume of complaints around hard to customize components seems to have gone down between v3 and v4 once we introduced the global class names.
Ideally it should've been part of the RFC process.
This is one of the first dimensions we have considered. I believe the section "Deterministic classnames on the components that can be targeted for custom styles" surfaces this, but we could have exposed it deeper.
@@ -11,6 +11,7 @@ import { | |||
unstable_capitalize as capitalize, | |||
unstable_useControlled as useControlled, | |||
} from '@material-ui/utils'; | |||
import sliderClasses from './sliderClasses'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need a different file to host this file? If we do, should we write it in TypeScript directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've extracted it in a separate file as it needs to be used in both components files (Slider & SliderValueLabel). I think it's better to have it separately for easier navigation. Converting it to ts makes sense, let me do that 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are some ts errors when converting this to ts file - https://app.circleci.com/pipelines/github/mui-org/material-ui/27322/workflows/7aed2605-b9fb-42e8-81d1-5b6e10ccb916/jobs/197097. Let me leave it as is and address as a follow up PR as it seems like we need to do changes with the build
classes['root'], | ||
getUtilityClass(`color${capitalize(color)}`), | ||
sliderClasses[`color${capitalize(color)}`], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will we get requests to support <Slider color="error" />
? No idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see the concern, should we maybe use the dynamic method for dynamic props? And have in the sliderClasses the ones we support by default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the other hand we could not do this changes, and leave as it was before with the getUtilityClass
utility, and export hte classes just for the sake of the clients being able to use them, and use them also in the tests...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know. The propTypes are another bottlneck. I think that we can wait.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, let's leave it open again for visibility
This doesn't make it easier, objectively. |
🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁 |
I can't wait to see how developers upgrade and play with the new slider :D |
Breaking change
@material-ui/styles
to@material-ui/styled-engine
.This PR replaced the
Slider
in@material-ui/core
with theSliderStyled
component from the lab.Changes done as part of the PR:
The files from
@material-ui/lab/SliderStyled
files are now replacing the@material-ui/core/Slider
. During the replacement we found several bugs that were not caught previosly because we didn't have screenshot comparison with the Base slider. All of them are fixed now.In addition to this, we renamed the
ValueLabelUnstyled
components toSliderValueLabelUnstyled
. The componentValueLabelStyled
was removed and the styles are now part of theSliderStyled
in order to ensure we are consistent with the specificity of two for all slots inside the Slider.