Skip to content
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

Merged
merged 130 commits into from
Nov 19, 2020

Conversation

mnajdova
Copy link
Member

@mnajdova mnajdova commented Oct 29, 2020

Breaking change

  • [Slider] Move the implementation from @material-ui/styles to @material-ui/styled-engine.

This PR replaced the Slider in @material-ui/core with the SliderStyled 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 to SliderValueLabelUnstyled. The component ValueLabelStyled was removed and the styles are now part of the SliderStyled in order to ensure we are consistent with the specificity of two for all slots inside the Slider.

@mui-pr-bot
Copy link

mui-pr-bot commented Oct 29, 2020

@material-ui/core: parsed: +1.29% , gzip: +1.47%
@material-ui/lab: parsed: -10.76% 😍, gzip: -13.65% 😍

Details of bundle changes

Generated by 🚫 dangerJS against 641be42

@mnajdova
Copy link
Member Author

mnajdova commented Nov 17, 2020

@oliviertassinari & @eps1lon I would kindly ask you for final review, as I've addressed the last comment #23308 (comment)

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Nov 17, 2020
@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Nov 17, 2020
| <span class="prop-name">defaultValue</span> | <span class="prop-type">Array&lt;number&gt;<br>&#124;&nbsp;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. |
Copy link
Member Author

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

Copy link
Member

@oliviertassinari oliviertassinari left a 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&lt;{ label?: node, value: number }&gt;<br>&#124;&nbsp;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. |
Copy link
Member

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?

Copy link
Member Author

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': {
Copy link
Member

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';
Copy link
Member

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?

Copy link
Member Author

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 👍

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Copy link
Member Author

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)}`],
Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member Author

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...

Copy link
Member

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.

Copy link
Member Author

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

@eps1lon
Copy link
Member

eps1lon commented Nov 18, 2020

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

  1. How did you get that impression?
  2. How is that an argument? Should we use bit-wise operations because people are already familiar with JS?

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.

This doesn't make it easier, objectively.

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Nov 18, 2020
@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Nov 18, 2020
@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Nov 18, 2020
@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Nov 19, 2020
@mnajdova mnajdova merged commit 4b71794 into mui:next Nov 19, 2020
@oliviertassinari
Copy link
Member

🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁

@oliviertassinari
Copy link
Member

I can't wait to see how developers upgrade and play with the new slider :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change component: slider This is the name of the generic UI component, not the React module!
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants