[DataGrid] Allow to set in GridExportCsvOptions delimiter

[michallukowski]

Add option in GridExportCsvOptions to set delimiter character

Fix 1. of #1440

[dtassone]

FYI the comma as decimal separator is according to the culture. So in the uk they use 1, 000 and in Fr, they use 1 000 I think.
So not sure we should add it as an option. Maybe we could think of an export formatter as @m4theushw mentioned somewhere (trying to recover his comment)

[michallukowski]

FYI the comma as decimal separator is according to the culture. So in the uk they use 1, 000 and in Fr, they use 1 000 I think.
So not sure we should add it as an option. Maybe we could think of an export formatter as @m4theushw mentioned somewhere (trying to recover his comment)

You're talking about the thousand separator. Using Number.prototype.toString() we don't get the thousands separator which I think we shouldn't use in CSV. For example, in many European countries, the number 3.14 in the csv file is automatically treated by Excel as a string. If the decimal separator is ',' (3,14), Excel detects as a number.
https://en.wikipedia.org/wiki/Decimal_separator

[m4theushw]

@michallukowski I proposed in #1814 (comment) that we apply the value formatter to the CSV export too. With it, you would be able to change how numbers are formatted when exported. This is what Damien refers to. Regarding this PR, I would avoid adding specific options to control number formatting. We could leverage Intl.NumberFormat that already provides everything. We could ask the user to pass a Intl.NumberFormat instance and use it to format values.

Using Number.prototype.toString() we don't get the thousands separator which I think we shouldn't use in CSV.

Number.prototype.toLocaleString() gives the formatted value according to the current locale.

[oliviertassinari]

Can we add a test case for the new delimiter param?

Using Number.prototype.toString() we don't get the thousands separator which I think we shouldn't use in CSV.

Agree, I don't see why we would want to format a number in CSV exports. It seems better to be able to rely on the CSV reader to automatically detect a number and handle it accordingly (e.g. for formatting based on the locale of the CSV reader or further math operations).

[dtassone]

Yes so basically don't do anything special for numbers, we should consider using formatters on export

[DanailH]

Can we add a test case for the new delimiter param?

Using Number.prototype.toString() we don't get the thousands separator which I think we shouldn't use in CSV.

Agree, I don't see why we would want to format a number in CSV exports. It seems better to be able to rely on the CSV reader to automatically detect a number and handle it accordingly (e.g. for formatting based on the locale of the CSV reader or further math operations).

This reminds me that I don't think that the CSV export currently uses the valueFormatter although it does use valueGetter.