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.14k stars 1.29k forks source link

[RFC] Improve x-grid-data-generator management #226

Open oliviertassinari opened 4 years ago

oliviertassinari commented 4 years ago

Considering the package is MIT, I don't think that it should be prefixed with x-, hence the proposal in the title.

oliviertassinari commented 3 years ago

One possible approach for the future. The package is for demo only purposes, so simplicity should be prioritized:

It could be interesting to bring in the folder import structure we have in the main repository and allow to do things like:

import { useDemoData } from '@material-ui/x/dataGenerator'; // non MIT license

To remove the need for more packages (the fewer, the less mess to manage).

Also, considering that we might need a data generator for other components, like a chart or a scheduler, I would suggest that we make the above the only valid import, avoiding the need to duplicate it between different packages as we have done in #887 for the sake of simplicity (but I don't think that it will scale).

DanailH commented 3 years ago

I assume we should also follow the same pater for the x-grid so it will become -> @material-ui/x/data-grid.

And the MIT version will be @material-ui/data-grid.

oliviertassinari commented 3 years ago

the x-grid so it will become -> @material-ui/x/data-grid

@DanailH I don't think that it's an option because we need the nested import to match the exported name, this would work:

import XGrid from '@material-ui/x/XGrid';

In any case, I think that we can delay the conversion to the point in time we add a second component. We could also very well imagine removing individual packages @material-ui/x-grid and @material-ui/data-grid for global ones:

@material-ui/x-light the MIT modules and @material-ui/x the GPL/commercial license.

Just a thought, no idea if it's better.

dtassone commented 3 years ago

From a user perspective, I think it's nice to be able to install just the required component. @material-ui/x-grid

oliviertassinari commented 3 years ago

install just the required component

@dtassone Yeah, I think that it comes down to what developers most often need. Basically, we need to draw the distribution of the number of imported packages among our userbase to know. I doubt it's data we can easily access to. GA could yield some indicators. A survey might be interesting too.

  1. If they end up using many of the components of the kit in their application, then a single package is obviously (learned from 6 years of XP on the main repo) what most developers will choose.
  2. If they end up only using a couple of the dependencies, then they will probably prefer individual versions.

I think that by definition, the usage of advanced components makes 1 less likely than for generic design system components. However, I wouldn't be surprised if the data grid ends-up very frequently used, relatively to the other core components (the popularity of react-table and of the Table are two great indicators of the potential, if we execute correctly).

At the ends of the day, I think that it comes down to:

bundled packages pros:

individual packages pros:

m4theushw commented 2 years ago

@oliviertassinari Is this issue still relevant after we renamed the packages?

flaviendelangle commented 2 years ago

https://github.com/mui/mui-x/pull/3965#discussion_r809227466

Can this package really be MIT since it needs a non-MIT package to work ?