[Spike] Having 2x CSV export methods (JS-based and server-based) adds complexity with little/no benefit to merchants. Can we simplify?

[Jinksi]

Problem
We currently have 2x implementations for generating CSV exports for reporting views, e.g. Transactions list, Payouts list, etc.

• front-end JS-based CSVs are exported for small row counts (<25-100)
• async service-generated for larger CSVs that are emailed to the accountholder

We should simplify this to reduce complexity, and maintenance footprint with the goal of improving the quality of the CSV export experience for our merchants.

Outcome
The outcome of this spike should be a proposal with one or more solutions for what we could change to reduce the complexity of CSV exports.

[haszari]

@Jinksi What's the outcome of this issue – a spike or a proposal for what we could change?

[Jinksi]

Thanks @haszari, I've added outcome and updated the title to clarify that this is a spike.

[haszari]

Shifting this to backlog, I've now proposed it as a project idea, if that project gets prioritised let's go!

[jessy-p]

Project idea link: paJDYF-g1S-p2

[jessy-p]

Based on pdjTHR-4t9-p2, moving this to Sprint

The goal of this project is to deprecate (if needed) and remove the plugin CSV render code, and make any necessary fixes or improvements to the async (server) flow.

We have go-ahead for the project, but we still need to make sure everyone’s aligned and on board with the change.

[nagpai]

I am closing this spike since we have achieved the outcome of having a proposal and a project thread.

Ref:

• Project idea - paJDYF-g1S-p2
• Project thread - paJDYF-g5h-p2