[slider] Replace core Slider with SliderStyled#23308
Conversation
|
@material-ui/core: parsed: +1.29% , gzip: +1.47% |
| | <span class="prop-name">componentsProps</span> | <span class="prop-type">object</span> | | The props used for each slot inside the Slider. | | ||
| | <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.
The defaults are now in the SliderUnstyled, not here
oliviertassinari
left a comment
There was a problem hiding this comment.
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.
Default values are missing. What do you think of "pulling" the values from SliderUnstyled?
There was a problem hiding this comment.
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
| }, | ||
| }, | ||
| track: { | ||
| '& .MuiSlider-track': { |
There was a problem hiding this comment.
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.
| unstable_capitalize as capitalize, | ||
| unstable_useControlled as useControlled, | ||
| } from '@material-ui/utils'; | ||
| import sliderClasses from './sliderClasses'; |
There was a problem hiding this comment.
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.
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.
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
| sliderClasses['root'], | ||
| classes['root'], | ||
| getUtilityClass(`color${capitalize(color)}`), | ||
| sliderClasses[`color${capitalize(color)}`], |
There was a problem hiding this comment.
Will we get requests to support <Slider color="error" />? No idea.
There was a problem hiding this comment.
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.
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.
I don't know. The propTypes are another bottlneck. I think that we can wait.
There was a problem hiding this comment.
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/stylesto@material-ui/styled-engine.This PR replaced the
Sliderin@material-ui/corewith theSliderStyledcomponent from the lab.Changes done as part of the PR:
The files from
@material-ui/lab/SliderStyledfiles 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
ValueLabelUnstyledcomponents toSliderValueLabelUnstyled. The componentValueLabelStyledwas removed and the styles are now part of theSliderStyledin order to ensure we are consistent with the specificity of two for all slots inside the Slider.