search

mui / mui-x

MUI X: Build complex and data-rich applications using a growing list of advanced React components, like the Data Grid, Date and Time Pickers, Charts, and more!
https://mui.com/x/
4.52k stars 1.31k forks source link

[data grid] Add support for Joy UI #11118

Open oliviertassinari opened 11 months ago

oliviertassinari commented 11 months ago

Summary 💡

Allow user to easily set up a Joy design on their data grid components.

Examples of users needing this

Solution exploration

chyzwar commented 9 months ago

Do you plan to work on Joy design support for mui-x v7 ? I working on new application that use joy-ui and I am trying to understand if mui-x will be viable option for DataGrid.

oliviertassinari commented 9 months ago

@chyzwar there are no plans to improve Joy UI support in MUI X v7. However, it's possible to have a Joy UI data grid for you by replacing slots and restyling elements.

This workaround comes with downsides:

  1. It's time consuming
  2. The execution doesn't benefit from network effects (open source contribution polishes and fixes)
  3. Material UI stays in the bundle

Because developers can't do anything about 3. I think it's the first problem we should solve, this is https://github.com/mui/mui-x/issues/10143.

Once solved, then I think we could solve 1. and 2 by having a built-in default style layer, which this issue is about.

chyzwar commented 9 months ago

Thank you for letting me know about future plans. I will go with workaround and re-style DataGrid to match joy-ui.

For me, Joy-UI is great because it is share high quality underlying implementation with material-ui without obnoxious design of material design. I see that material-ui team is doing now much more (base-ui, mui-x, md v3, zero runtime) I hope that Joy will not get neglected.

oliviertassinari commented 9 months ago

Joy-UI is great because it is share high quality underlying implementation with material-ui without obnoxious design of material design

@chyzwar I'm 💯 aligned with this. I have a friend who uses Joy UI over Material UI because of this. It's also why I would use Joy UI.

Work on Joy UI is right now delayed https://mui.com/blog/2023-material-ui-v6-and-beyond/#a-sharper-focus. This is because of https://npm-stat.com/charts.html?package=%40mui%2Fjoy&from=2022-02-01&to=2024-02-01, there is not enough developer traction relative to its opportunity cost, I think we learned that for Joy UI to work, we need a larger team on it but at the same time we are clearly spread too thin with Material UI, not enough R&D spent on it, it's lagging. Material UI is no longer held back by Material Design as when we started the effort on Joy UI (but helped back by the same things that hold Joy UI back), so we refocused the effort on Material UI to solve these problems. Meaning the judgment call is that right now, there is more ROI on time spent on Material UI than Joy UI.

The good news: we doubled the Core team ~6 months month ago, and are hiring to double this product group again. I suspect this will give us enough bandwidth to cover the scope of Joy UI but this time stand out with more focus and having the main bottlenecks we identified solved.

However, from a developer standpoint, we will likely have Joy UI and Material UI API a lot closer, differentiating with the default look & feel for end-users. I would expect breaking changes.

Speaking under @siriwatknp's control, this is how I understand the situation.

kamavingah commented 5 months ago

Adding a link to https://github.com/mui/material-ui/discussions/29024#discussioncomment-9434308 since it's relevant to this issue