[RFC] Package structure

[oliviertassinari]

This is a follow-up on a couple of past discussions we had, mostly speaking. I couldn't find any written conclusion on how to best name the package and components outside of a verbal discussion that no other member can introspect. In order to improve decision making and transparency, I'm making a written RFC, so we can settle.

Introduction

We came to the conclusion at https://github.com/mui-org/material-ui-pickers/issues/1778 that:

• All the components exposed in Material-UI are in a single namespace.
• How we structure the npm packages should be only driven by "deliver" concerns. So far:
  • isolating MIT and enterprise licenses, legal concerns: @material-ui/core vs @material-ui/x.
  • testing if it helps increase market share, also help to provide KPI to assert the quality of our work: @material-ui/pickers.
  • share code between multiple packages: @materal-ui/utils.

Problems

Looking at the current naming organization, I see a couple of things we could potentially improve:

• The Grid component name is already reserved by https://material-ui.com/api/grid/. We can't use it here.
• I believe it would be better not to have an intermediary /grid folder. A flat structure would be easier to navigate.
• It seems that the intermediary /grid was introduced to fix a naming organization issue: if we sort ASC, related components won't be grouped. This might be an issue we would want to solve userland too (not only in the repository).

Solutions?

A couple of options that we could consider to solve the above:

1. We could put emphasis on the components, paid or not. This would enable to flatten the file structure. Moving from:

/data-grid
/x-grid-data-generator
/x-grid-modules
/x-grid
/pickers
/x-pickers
/x-tree-view

to

/data-grid
/grid-x-generator
/grid-x-modules
/grid-x
/pickers
/pickers-x
/tree-view-x

I've not convinced it's better, but it could have its advantages, to consider.

2. We could simply remove the intermediary /grid folder. I think that it would make it easier to navigate the codebase.
3. We could consider that the Enterprise version of the component is meant to completely replace and extend the MIT version. I think that it would create a good constraint for the developer experience. We would only document one component, with props that are restricted to X with a dedicated notice. In practice, it would mean:

import { DatePicker } from '@material-ui/pickers';
import { DateRangePicker } from '@material-ui/x-pickers';
// import { DataGrid } from '@material-ui/data-grid';
import { DataGrid } from '@material-ui/x-data-grid';

4. In the even 3. it not identified as the best approach, we can differentiate the two components (free and paid):

import { DatePicker } from '@material-ui/pickers';
import { DateRangePicker } from '@material-ui/x-pickers';
import { DataGrid } from '@material-ui/data-grid';
import { XGrid } from '@material-ui/x-grid';

[oliviertassinari]

Problem solved, we went with

import { DatePicker } from '@material-ui/pickers';
import { DateRangePicker } from '@material-ui/x-pickers';
import { DataGrid } from '@material-ui/data-grid';
import { XGrid } from '@material-ui/x-grid';