Provide a version of the components without any styles

[kof]

Material-UI as "material to build UI", not "material design"!

I am wondering if it would make any sense to extract the core components of material-ui in a separate, completely non-opinionated and naked library and make all material-ui specific design decisions a theme + stuff like Ripple.

As an outcome I would expect:

• A very high adoption of the core library
• More contributors to the core
• Clear separation between those two
• Users could choose between material-ui and other styles and switch when needed.

[oliviertassinari]

@kof Thanks for starting this discussion. You have opened quite some interesting issues lately.
What do you have in mind with core components? Does this discussion take into account a unstyled version of the library?

[kof]

unstyled version of the library

Exactly, I called it naked ui, it should be just core stuff required for every theming/ux.

From my perspective of the next codebase, much of the modules that we could extract away from the lib have already been extracted. We don't try to reinvent the wheel.

I think a lot more is not really material-ui specific but generic and we can do more generic if we use variants #6130

[kof]

For e.g. the components innside of internal/** look like mostly generic also I see more stuff can become generic.

[kof]

Just from what I have looked into: Form, Divider, Avatar, Icon, Input and probably lots of others can be also generic nacked components and mui just a theme + variants on top.

[oliviertassinari]

Thanks for clarifying your motivation.
I see two ways to move forward into that direction.

1. We decouple the styles from the components. Meaning that we would expose unstyled components that accept a classes property object with various customization class names points.
   Then, to expose the material version, we would have to wrap all those naked components with an Higher-order Component.
2. If we move forward with Universal variations interface using "variant" prop #6130, we could allow users to override all the rules using the theme. We could imagine adding an option to start from unstyled rules.

[kof]

In order to achieve naked components we would need to implement #6130 first anyways. Also naked components would need some core styles, theme unrelated.

[mbrookes]

Reminds me of Reapp -the very first React component library I tried for the personal project that ultimately led to my involvement in Material-UI. :-) (In fact, I'm almost certain I discovered React from it, not the other way around!).

The components had no inherent styling (https://github.com/reapp/reapp-ui/tree/master/src/components, and a theme included the style objects for each component: https://github.com/reapp/reapp-ui/tree/master/src/themes/ios/styles

Only the iOS theme was developed, but the intention was that it could support Material Design, or other styles.

I think there was a certain naivety in that, since looking at the more complicated components in Material-UI such as the pickers (as malformed as they may be), some of the sub-component hierarchy and functionality is dictated by the design that the component is aiming to meet.

Making that generic could be tricky. (Not impossible, but certainly an added burden.). All that said, I'm certainly on-board with the idea in principal, but I'll leave it to those smarter than me to figure out the implementation details.

[kof]

Yeah, such complex components like Datepicker are hard to make generic and probably not a good idea too. They may be implemented within material-ui but using all the generics from the nacked library.

A nacked library can provide though all necessary parts for it, so that assembling own custom picker is not as hard any more.

[jgoux]

I like this. 👍

In a perfect world we'd have a style-independent repository with core-components that we can use across multiple projects with theme adapters. (Like a material theme, a bootstrap theme...).

There is this repository : https://github.com/react-component/ which follow more or less the same idea, minus the styles that don't seem "open".

[stunaz]

If it is gonna take years to implement, I really don't think it is a good path to follow. I'd rather have material-ui focus only on material design component implementation with react.

[Zuurkern]

@stunaz I agree we should focus on porting more components to the next branch first and make them fully in line with Material Design guidelines. Also improve their APIs and generally make them more robust.

This is a great idea though and I'd love to see it implemented. Especially after reading #6130

[kof]

This is about next steps, for sure we need to release "next" first.

[esseswann]

Please don't fall into illusion of abstraction levels. As @stunaz @Zuurkern @kof say not all components are good material for that

[Janpot]

In case it could serve as inspiration, I remember the angular team coming up with what they call "a CDK" for their material UI library. https://blog.angular.io/a-component-dev-kit-for-angular-9f06e3b4b3b4

[oliviertassinari]

An update on the priorities. We plan to push this as soon as v5 has made enough progress. We will work on it hand in hand with #22485 to have a healthy constraint.

[michaldudak]

Status update: I recently joined the core team and unstyled components are my main focus.
As for the implementation I'm leaning towards having unstyled components using hooks. I published a draft of a PR with this approach and I'd love to know what you think about the proposed API.

You can follow our progress in mui/base-ui#10.

[avgspacelover]

I read this issue as a newbie today and i cannot understand how developers follow a specific feature for more than 5+ years as it seems really complex .is there any meaningful way for me to contribute to this feature ?

[mbrookes]

@antariksh17 The answer is linked in the comment above yours: mui/base-ui#10