[core] Allows to add custom export item

[alexfauquette]

This is a refacto of the export menu, to simplify #3802

The idea is to simplify the GridToolbarExport

const GridToolbarExport = React.forwardRef<HTMLButtonElement, GridToolbarExportProps>(
  function GridToolbarExport(props, ref) {
    const { csvOptions = {}, printOptions = {}, ...other } = props;

    if (csvOptions?.disableToolbarButton && printOptions?.disableToolbarButton) {
      return null;
    }

    return (
      <GridToolbarExportContainer {...other} ref={ref}>
        <GridCSVExportMenuItem options={csvOptions} />
        <GridPrintExportMenuItem options={printOptions} />
      </GridToolbarExportContainer>
    );
  },
);

Such that adding an export format could be done by defining new export

const MyToolbarExport = (props) => (
	  <GridToolbarExportContainer {...other} ref={ref}>
	      <GridCSVExportMenuItem options={csvOptions} />
	      <GridPrintExportMenuItem options={printOptions} />
		  <CustomExportMenuItem /> // for example <GridExcelExportMenuItem /> in DataGridPremium ;)
	  </GridToolbarExportContainer>
)

Each child of GridToolbarExportContainer receive a hideMenu method which allows them to hide the menu when clicked

[mui-bot]

These are the results for the performance tests:

Test case	Unit	Min	Max	Median	Mean	σ
Filter 100k rows	ms	213	539.4	442.8	388.12	145.046
Sort 100k rows	ms	487.8	933.9	584.8	682.74	186.316
Select 100k rows	ms	187.8	296.5	219	237.1	44.151
Deselect 100k rows	ms	116.4	257.7	192.2	187.16	45.591

Generated by 🚫 dangerJS against 156d99d

[siriwatknp]

👋 The migration PR has been merged.

Please follow these steps to make sure that the contents are all updated. (Sorry for the inconvenience)

1. pull latest master from upstream to your branch
2. if your PR has changes on the *.md or demo files, you are likely to encounter conflict because all of them have been moved to the new folder.
   2.1 revert the change on those markdown files you did
   2.2 pull latest master from upstream (you should not see conflict)
   2.3 make the changes again at docs/data/data-grid/*
3. run yarn docs:api
   • you might see the changes in docs/pages/x/api/data-grid/* if your PR touches some of the components
   • it is okay if there is no changes

If you are struggle with the steps above, feel free to tag @siriwatknp

[alexfauquette]

@flaviendelangle I added a section in the doc to explain how to add a custom export

I'm wondering if I should tag this demo as pro, because adding a menu item can be done with the community version, but to make the export, the developer needs to access the data. Without selectors, this part is fairly complicated

[flaviendelangle]

@alexfauquette All your demo can be done on the community plan
useGridApiContext and the selectors are exported by @mui/x-data-grid

[alexfauquette]

Should we rewrite the doc on access the state?

[flaviendelangle]

For me we are in an inconsistent scenario.
That's the main reason why I want to open the apiRef
Because if you document the state access on the Community version, people will wonder why they can only access it in the component slots.
So until now, my policy was to not document it explicitely for the state access but to do the demo with DataGrid whenever possible.

This situation should be solved in a few weeks.
With the new typing we merged on Monday, creating a public / private API and releasing the apiRef for the Community plan should be simple.

---

EDIT: You have the exact same thing for all the apiRef sections on the various doc pages