[DataGrid] Implement CSV export

[oliviertassinari]

We have started to work on the feature a year ago, the person that takes on this task can refer to mui/material-ui#18872 and this code: saveAs.

Research

UIs inspiration I could find:

1. Google Ads

The "More options" button opens a modal where you can select the format of the CSV file.

2. Airtable

3. Retool

4. Redash

5. Stripe

6. https://try.firetable.io/table/mvpResources

Benchmark

• https://ag-grid.com/javascript-grid-export/#export
• https://material-table.com/#/docs/features/export
• https://www.zinggrid.com/docs/features/exporting-data
• http://tabulator.info/docs/4.7/download#csv
• https://js.devexpress.com/Demos/WidgetsGallery/Demo/DataGrid/ExportToExcel/React/Light/
• https://www.jqwidgets.com/react/react-grid/#https://www.jqwidgets.com/react/react-grid/react-grid-dataexport.htm
• https://datatables.net/reference/button/csvHtml5

[keremgocen]

What would be the recommended path for current material-ui consumer apps to design a CSV export feature? I'd like to be able to switch to material-ui table / datagrid once that's ready without doing the whole thing again if possible.

[oliviertassinari]

@keremgocen I think that you would depend on #190. We need to expose an API to integrate with the state of the data grid.

[AleKrabbe]

Hi, is there a date for this to be released? We are urgently needing to export our XGrid table into a CSV file. Thank you.

[oliviertassinari]

@AleKrabbe we aim to implement this feature Q1 2021. We mention it in the public roadmap: https://github.com/mui-org/material-ui-x/projects/1.

[DanailH]

Ok so I was thinking about how to handle the UX part and this is what I managed to come up with:

The main challenge is to make the UX in such a way that can handle also Excel export in the future if we choose to do it. I would propose to go in the direction of having a button per export option in the toolbar - my argument is that this way developers can opt-in on any option and this will also make the UI simpler since I can predict that we would need at least 2 options per export type (to export all or to export only selected rows).

Also, I propose we do a hook per export type because that way it will be easier to split them between the open-source and enterprise versions of the data grid.

On the props side, we would need a handler like onCsvExport for when developers would want to get the data. I don't think we would need a prop to enable or disable the feature since it will be opt-in (from the toolbar), the API will be available through the apiRef.

In terms of the API - most likely we would need 2 methods, one to get the data in a CSV format and one to download it.

[oliviertassinari]

• For the UX. Have you considered an hybrid approach? We could have a single component: GridToolbarExport. Depending on the features available, CSV, Excel, PDF, we would either display a single button or a menu. This would allow to have a denser UI and allowing end-users to prune the decision tree when navigating the interface. Basically, it would become a two steps process 1. Find the export location, 2. Pick the right format
• Regarding the code splitting. One hook/plugin per export type make sense. It sounds like we don't have the choice.
• What's the use case for the onCsvExport prop? I mean, what's the difference with the imperative apiRef method that returns the data in a string CSV format?
  Giving it more thoughts, it sounds like the prop will be available on the export toolbar button and allow to bypass the apiRef imperative methods. Why not.

[DanailH]

For the UX. Have you considered an hybrid approach? We could have a single component: GridToolbarExport. Depending on the features available, CSV, Excel, PDF, we would either display a single button or a menu. This would allow to have a denser UI and allowing end-users to prune the decision tree when navigating the interface. Basically, it would become a two steps process 1. Find the export location, 2. Pick the right format

First I thought of doing it like this, my argument against it is that if we want to have functionality like export all or to export only selected rows for example that would mean that we need a second level in the menu. I'm not saying it is bad but the downside is that it won't be the best experience on mobile, but if that is not a concern I prefer it that way.

Another concern is that if someone wants to have PDF export but not CSV for example if they are in the same menu we would need to introduce a prop to disable each one of them. If we make them as separate buttons since they are all opt-in separately we will avoid that case.

What's the use case for the onCsvExport prop? I mean, what's the difference with the imperative apiRef method that returns the data in a string CSV format?
Giving it more thoughts, it sounds like the prop will be available on the export toolbar button and allow to bypass the apiRef imperative methods. Why not.

Yes exactly - also this will allow for devs to be able to react to that action - maybe redirect or display something, etc. I can also delay adding it and see if there will be a demand for it.

[oliviertassinari]

OK, for the toolbar, we can go with a simple approach. If it doesn't work, we will hear about it.

Should it be an icon button to safe horizontal space?

[DanailH]

I made a draft, let's move the discussion regarding the UI there, it will be easier to follow it and address it.

[oliviertassinari]

4 UIs inspiration I could find added to the original comment #197 (comment).