base-ui
base-ui copied to clipboard
mui
Unstyled components progress
As discussed in https://github.com/mui-org/material-ui/issues/6218, we are committed to providing unstyled versions of the components in @base_ui/react. This is an umbrella issue to have visibility on the progress.
- [x] #25
- [x] #24
- [x] #213
- [x] #84
- [x] #215
- [x] #219
- [x] #214
- [x] #35
- [x] #185
- [x] #451
- [x] #218
- [x] #26
- [x] #649
- [x] #217
- [x] #216
- [x] #4
- [x] #212
- [x] #36
- [x] #32
- [x] #11
- [x] #31
- [x] #28
- [ ] #222
- [ ] #38
- [x] #51
- [x] #662
- [ ] #75
- [ ] #29
- [ ] #30
- [ ] #718
- [x] #220
- [x] #661
@michaldudak We heavily use the labels to function with our growing backlog of issues (13,000 at this point). I'm adding a new one.
@michaldudak should the list split into something like this to make it transparent to the community?
WIP (prioritized)
These components are prioritized based on the page views from analytics. ...
Done
...
The rest ...
Yeah, I think it may be a good idea to highlight the ones we'd like to tackle first. I marked these high-priority components with ⭐. As for WIP and Done - this information is there already. The ones with a PR but not completed are in progress, and checked ones are done.
@oliviertassinari I really want to contribute to this. Can you please assign me a component which is beginner friendly?
@imrishabh18 There are few components in @mui/material that don't have any styles:
- TextareaAutosize
- ClickAwayListener
- Portal
Moving them to @mui/core should be pretty simple. Take NoSSR as an example (#27356)
@michaldudak @oliviertassinari I'd like to contribute to this... could you assign a beginner friendly component?
@michaldudak @oliviertassinari we'd love to incorporate the unstyled version of the Tooltip component into a few of our projects. Has any work been done on it so far? — If not, I'd love to contribute by building the unstyled version. 😄
Outside of what is listed in the Contributing.md, are there any specific requirements and/or standards I should be aware of before starting? Would the unstyled Tooltip be dependent on the unstyled Popper?
We haven't got the standards for the unstyled written down as we are still in the process of defining them. Each new unstyled component that we make creates new challenges.
If you'd like to contribute, I think Popper may be a good place to start (and yes, it's a Tooltip's dependency). It already is pretty much unstyled, so you'd have to move it to the @mui/core package. We had a similar case with the NoSsr component. Take a look at its PR (#27356) to see how it was done.
@michaldudak @oliviertassinari I am really excited about this! This will allow us to use this with TailwindCSS, while there is headlessui but it lacks components.
Is there any reason why packages/mui-base/src/ModalUnstyled/ModalUnstyled.js doesn't use components.Backdrop instead of BackdropComponent? (same for the material one)
Moving forward I would assume that most configurations of the components would be under components
@michaldudak @oliviertassinari I am really excited about this! This will allow us to use this with TailwindCSS, while there is headlessui but it lacks components.
I would like to see Tailwind CSS in the examples for unstyled components, it would showcase the fact that you shouldn't need to be everything in CSS-in-JS and it will show people how to leverage Mui + Tailwind; which I think is a good business strategy nowadays.
Is there any reason why packages/mui-base/src/ModalUnstyled/ModalUnstyled.js doesn't use components.Backdrop instead of BackdropComponent? (same for the material one)
We still have to update a couple of older base components to have a consistent API. We aim to use components.* instead of *Component everywhere.
I would like to see Tailwind CSS in the examples for unstyled components, it would showcase the fact that you shouldn't need to be everything in CSS-in-JS and it will show people how to leverage Mui + Tailwind; which I think is a good business strategy nowadays.
Good point, we'll consider this when writing guides for the base package.
We still have to update a couple of older base components to have a consistent API. We aim to use components.* instead of *Component everywhere.
@michaldudak got it, wasn't sure if that was the case so that is why I asked.
I might be wrong about this (and a bit late to the party), but I'm not convinced that we should prioritize components based purely on docs page views. Some components must surely get more views simply because they're more complex. I would personally give a weighting to components that replace native HTML form controls, such as checkbox, radio, textfield (input), form label, etc. These are going to be more commonly used than say TablePagination, or Tabs.
Is there any reason why packages/mui-base/src/ModalUnstyled/ModalUnstyled.js
If the package is now called base, should the components be too?
I would personally give a weighting to components that replace native HTML form controls, such as checkbox, radio, textfield (input), form label, etc. These are going to be more commonly used than say TablePagination, or Tabs.
TablePagination and Tabs have already been done. We're working currently on the Select component. Other form inputs will follow early next year.
If the package is now called base, should the components be too?
Not necessarily. The Base package is more than just unstyled components. It contains hooks and other components that are not "stylable" at all (like NoSsr). Also, changing the suffix to "Base" would create ambiguity as we already have ButtonBase, SwitchBase, etc. in @mui/material.
TablePagination and Tabs have already been done.
I know, I did say I was late to the party. 😁 Just advocating for completing the more fundamental components before others in the remaining list.
@michaldudak while the following components are ignored but I think having built in components for those is valuable when looking from the accessibility perspective
Drawer, SwipeableDrawer,
Breadcrumbs, CircularProgress, BottomNavigation
@kaushalyap Thanks for the feedback. Once we create the components from the "included" list, we'll consider the others based on the community requests.
@kaushalyap We are finishing work on the last of the prioritized ones - Menu. Then we want to focus more on building the docs and creating instructional content. We may continue focusing more on the rest of the components in Q2 2022.
Something doesn't seem right with the priority here. If we don't support fundamental components first, the use of the more esoteric ones will be limited at best. On what basis are we prioritizing the components?
@michaldudak Seems site use GA, but most devs block client side tracking .
We took the most popular ones first (based on traffic on the docs).
I'm going to hazard a guess that the simpler and more frequently used a component is, the less likely it is that a developer needs to refer to the docs for it, especially with autocomplete in the editor. I don't thing docs traffic is a good proxy for importance here.
Not necessarily - the Button for example is pretty simple, yet it appeared at (or near) the top of our list.
Anyway, I believe we miss just the Checkbox and Radio/RadioGroup to have a full suite of basic components (of course we can argue what is a "basic" component). We will focus on them next.
