[Data Grid] Add experimental headless exports

[lauri865]

• I have followed (at least) the PR section of the contributing guide.

Trying to address my main gripe with the datagrid – we love the core of it, but we don't use Material UI. We have all custom slots in place already, but we cannot get rid of the default slots from our bundle. This is one suggested way to do this for now.

Adds a possibility to import:

import {
  Unstable_DatagridPro as DataGridPro,
} from '@mui/x-data-grid-pro/headless';

This would prompt the developer to provide all of their own base slots and icons (excl. core components like rows, etc.).

Addresses #10143, #12370, etc. partially at least, for the time being.

An alternative option would be to put all the material slots into a separate package, so we could, within our build tooling, resolve it easily to an internal file that exports an empty object.

Very open to feedback, if you think there's a better way to achieve this.

[mui-bot]

Deploy preview: https://deploy-preview-15662--material-ui-x.netlify.app/

Generated by 🚫 dangerJS against a2ad678

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[flaviendelangle]

The team is currently working to split the DataGrid logique and the @mui/material / @mui/emotion dependency.
The goal is not only to remove the components from the bundle size, but also the whole styling stack.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[romgrk]

Thanks but I'm already working on this, there's many aspects to take into consideration and this approach is too limited for what we're trying to do. I should have something available on the v8 alpha in a month or two. I'll close this PR to avoid duplicating work.

[lauri865]

Makes sense. Would you accept a simpler PR though where I move all material slot imports into a single file per datagrid type (community, pro, premium)? Currently, the import resolution tree is so complex, that we'd have to patch all 3 packages to remove material imports in the upper layer.

Currently:
DATA_GRID_PREMIUM_DEFAULT_SLOTS_COMPONENTS imports its material components, but also imports DATA_GRID_PRO_DEFAULT_SLOTS_COMPONENTS which imports material components and also imports DATA_GRID_DEFAULT_SLOTS_COMPONENTS which imports material components.

It'd be a pretty simple change to have material "themes" resolve their own components, which would then make it easier to rip them out as well.

While I'm sure you can come up with a 10x approach, I'm also quite certain it will have to come at a steep cost for adoption / migration. Which will take time, and thus a stopgap solution would be greatly appreciated.

[lauri865]

Something along these lines:
https://github.com/mui/mui-x/blob/82d46ab329a11bf9308e8a1cf57786ac0cec37ad/packages/x-data-grid-premium/src/material/index.ts

import type { GridPremiumIconSlotsComponent } from '../models';
import {
  GridWorkspacesIcon,
  GridGroupWorkIcon,
  GridFunctionsIcon,
  GridSendPromptIcon,
  GridRecordPromptIcon,
} from './icons';
import materialSlotsCommunity from '@mui/x-data-grid/material';
import materialSlotsPro from '@mui/x-data-grid-pro/material';

const iconsSlots: GridPremiumIconSlotsComponent = {
  columnMenuUngroupIcon: GridWorkspacesIcon,
  columnMenuGroupIcon: GridGroupWorkIcon,
  columnMenuAggregationIcon: GridFunctionsIcon,
  toolbarPromptSendIcon: GridSendPromptIcon,
  toolbarPromptRecordIcon: GridRecordPromptIcon,
};

const materialSlots = {
  ...materialSlotsCommunity,
  ...materialSlotsPro,
  ...iconsSlots,
};

export default materialSlots;

[romgrk]

I'm planning to do a refactor of that kind in the next weeks, and I think I already have it done to some extent in #12432 (though I'll probably reuse that PR for parts).

I will however be working on getting rid of material-ui style-engine and typings first, so this part (the components) would be the last one of the design-agnostic refactor.

Would you accept a simpler PR though where I move all material slot imports into a single file per datagrid type (community, pro, premium)?

I understand that this is a priority for you so if you want to make a very very simple PR that's enough to keep you happy for the time being, I will review it, but I can't guarantee that we will merge it if there is a potential conflict with the ongoing work. In other words, I don't recommend that you do it, but it's not a strict no.