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

[oliviertassinari]

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

[oliviertassinari]

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]

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]

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]

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

[oliviertassinari]

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:

• Simplicity for developers to install
• Simplicity for developers to update

individual packages pros:

• Mitigate the feeling of fear of bloat (technically, it might/likely doesn't matter but emotions are strong and often matter more in the decision making process)
• A way to get some of the pros of the bundled package approach is to enforce a single unique version

[m4theushw]

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

[flaviendelangle]

#3965 (comment)

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