CSV export client side

[6pac]

Hey @ghiscoding , do you have any libraries for client-side export of grid data to CSV? I did a quick search of Slickgrid-Universal but couldn't find anything.

Also, did you notice the new pivot example?

[ghiscoding]

I do have Export as CSV or Tab Delimited and it's a service/package that is optional, which basically loops through all rows of the DataView which I'm using exclusively in my libs. The service is shown below and I use 1 external lib text-encoding-utf-8 for encoding.
https://github.com/ghiscoding/slickgrid-universal/blob/master/packages/text-export/src/textExport.service.ts

I also have another service/package for Excel export but it requires a couple more 3rd party libs
https://github.com/ghiscoding/slickgrid-universal/blob/master/packages/excel-export/src/excelExport.service.ts

The reason I never added an export plugin here is that I don't use SlickGrid plugins directly anymore since I have my own, so I never spent the time to copy and adapt my services to be written as a plugin here and also because I use external lib. At the time, I started my export services from this Stack Overflow QA: https://stackoverflow.com/questions/11503007/slickgrid-functions-for-csv-export

I did see your new pivot Example but I never quite understood the pivot concept so there isn't much I could say about it. I didn't see any dynamic pivot creation though ;)

[ghiscoding]

hey @6pac I also created PR #894 and it would be nice to get feedback on the idea and concept.

[6pac]

Thanks, that's extremely helpful.

Re pivoting, I've only got it working for reporting so far, so a read-only grid. These were my requirements at the time. The pivoting is done in JS. This is the hard part done though, so it wouldn't be hard to get dynamic pivoting and updateable editing working.

re #894 I suppose this is a necessary evil. This is part of a trend for establishing best practice that can't be unsafe no matter how bad the code is. You can tell I'm not personally enthusiastic about it, but in terms of positioning Slickgrid for widespread use, this is an important box to tick.
It all looks pretty straightforward - passing the node to the formatter works, and I assume you'll have an option flag for the formatter style since it will be majorly breaking. The precompiling in the DataView looks pretty tricky, but I wonder if this is even necessary nowadays - it's a long time since this technique was added to DataView. Possibly with JIT compiling etc, it's no longer an advantage. This would require a performance test to determine.

[ghiscoding]

Yeah they want to enable CSP in our company and even if I have fixed some of the issues, there are some more that will be a problem in the near future. Both of them, innerHTML in SlickGrid and the use of new Function in DataView, they will both require some time to refactor and troubleshoot.