[Slider] Extract slots as standalone components

[mnajdova]

This PR transforms the slots inside the Slider as standalone styled components. This will allow us to support back the classes prop on this component. Plaground for testing the classes prop here -https://codesandbox.io/s/continuousslider-material-demo-forked-40y7u?file=/demo.js

[mui-pr-bot]

@material-ui/lab: parsed: +0.21% , gzip: +0.17%

Details of bundle changes

Generated by 🚫 dangerJS against 1007f6f

[mnajdova]

Closing, as it was done for experiment only

[mnajdova]

I'll need to update the buildAPI script again to extract info from the proptypes classes prop, currently it depends on the component.styles which is something we are adding for the components created with withStyles. However I would like first to see whether we agree with this approach, before spending too much time on it.

[mnajdova]

Playground for testing classes prop - https://codesandbox.io/s/continuousslider-material-demo-forked-40y7u?file=/demo.js

[oliviertassinari]

This trade-off is tough. Initially, we have started to work in this pull request in order to evaluate the performance implication. We shared the results in #22342 (comment), then started to engage with the community about it. To summarize we have:

pros for dropping classes:

1. the API was meant for JSS, there aren't any real use cases outside of it. Assuming JSS is here to fade, the prop is, long term, extra weight with no value.
   jQuery UI added the prop and justified it for global .css file switch. Same rationale in react-autosuggest. Does it really make sense?
2. each extra styled component slows things down. For instance, take the Button, we will need one for the root and one for the label. We have measured a 20% performance decrease with the slider ([RFC] v5 styling solution 💅 #22342 (comment)). The slider has 7 intermediary elements. For the data grid, it's highly unlikely that we can accept this degradation, at least, for the grid viewport.
3. early feedback from the community on the discussion were: -20% of performance? drop it.

pros for keeping classes:

4. makes the migration from v4 to v5 easier. Without, developers that customize the components will need to rewrite.
5. specificity if flatten usually, it means simpler customizations.
6. When there are multiple intermediary components. emotion CSS injection priority only works if the styles are applied to the same component. If you target a different one, you need to increase specificity to win. Having a specificity of one by default help. I think that it also helps SASS users as they don't need to nest selectors, they can write them flat.

Happy to go in this direction

Updated

[oliviertassinari]

A note for the second component we will migrate, we might want to abstract this helper, we will need it everywhere

[mnajdova]

Yeah, makes sense, probably there will be other things that can be abstracted, but for the thing I wasn't sure I just added them inline for now :)

[oliviertassinari]

Yeah, better until we know for sure :)

[mbrookes]

This discussion reminds me of something 🤔

(something wet... 😉 )

[mnajdova]

It was too fresh not to use it 😅

[mnajdova]

I am merging this one so I can update #23308 I can address any additional comments there.