Netlify deploy preview

https://deploy-preview-38021--material-ui.netlify.app/

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against 2ab4694

@oliviertassinari I was thinking of removing the default slots proptypes and exports, for example the default root slot proptypes and export.

Joy UI's Slider does not have the default slots proptypes, should we follow that in Material as well? Is there a reason to keep them?

Joy UI's Slider does not have the default slots proptypes, should we follow that in Material as well? Is there a reason to keep them?

1. 👍 to eventually have the same solution between Material UI and Joy UI. It wouldn't make sense to me to approach this differently in the long run but only differently as a transition phase to learn what's best.
2. https://mui.com/material-ui/react-slider/#customization has an example use case for exporting SliderThumb to later recompose with it.
3. I suspect that exposing all of these nodes, so developers can compose with them would get us one step closer to the one DOM node <> one public React component optimum DX, ejecting the code being the most extreme API in this direction.
4. In the doubt, we could keep the export limited to what we already support, to not have any BCs, which in practice, is "almost" all the slots we have in Material UI 😁, by almost, I mean, the cases where we don't, we mostly already do indirectly. Or we could remove these exports, and wait for developers to motive why we should expose them back. Happy either way.

PR got out of date as it has been on hold for a while. Closing as stale.

We'll have to revisit this later this year while working on v7.