[Feature] Support exporting chart data to CSV

[abzalzhaksylyk]

What problem does this feature solve?

Many dashboard applications allow users to export the underlying chart data for further analysis, reporting, or sharing. While ECharts currently supports exporting a chart as an image, there is no built-in way to export the displayed data as a CSV file.

Today, developers need to implement their own CSV export logic for every chart, even though ECharts already has access to the data being visualized. This results in duplicated effort across projects and inconsistent implementations.

A built-in CSV export would provide a consistent, reusable solution for a common requirement in analytics and business applications.

If this feature were available natively in ECharts, it would reduce implementation effort for many developers and provide a more complete end-user experience.

Note: I hope you’ll consider adding this feature. If it’s accepted but not something the team plans to implement in the near term, I’d be happy to contribute a PR :)

What does the proposed API look like?

One possible approach would be to extend the existing toolbox.feature API with a built-in CSV export option.

option = {
  toolbox: {
    feature: {
      saveAsImage: {},
      saveAsCSV: {
        show: true,
        filename: 'chart-data'
      }
    }
  }
};

When the user clicks Export CSV, ECharts would generate and download a CSV containing the data currently represented by the chart.

[plainheart]

Thank you for raising this feature request. Exporting CSV data is indeed a common requirement for dashboards and analytics applications.

To avoid bundling CSV, PDF, XLSX, and their potential third-party dependencies into the ECharts core package, I suggest a plugin-based approach: ECharts core would expose stable extension points for export capabilities and Toolbox features, while an independent export-toolbox package would provide image, CSV, PDF, and other exporters on demand. The plugin could support both a UI entry such as toolbox.feature.exportData and a programmatic API such as exportChart(chart, { format: 'csv', ... }), with both paths sharing the same export implementation.

The CSV data source should remain explicit and configurable, for example, by accepting table data directly or a getTable() callback. In the future, ECharts core could also expose a stable read-only data snapshot API to cover more complex cases involving dataset, transforms, encodes, and multiple series. This would address the saveAsCSV use case while preventing the core bundle and API surface from growing indefinitely as more export formats are requested.

Related issues: #21038 #5644 #15250 #18979 #20142 #5825 #5181

[abzalzhaksylyk]

Thanks for the detailed proposal. Plugin-based approach makes sense to keep the ECharts core lightweight while enabling the export capabilities.

Since this issue has been added to the 6.x milestone, I'm curious, does the core team plan to implement this feature, or is the milestone intended to track community contributions?

[plainheart]

I do plan to implement this feature, although I do not have a concrete timeline yet. The milestone is primarily intended to track the work and community interest around it.

Feedback and community contributions are very welcome as well, so if you would like to work on it, please feel free to open a PR. We would be happy to review it and help guide the implementation.

[abzalzhaksylyk]

Thanks for the update! It’s great to hear that you plan to implement it.

I’m asking because I'm currently evaluating whether to build my own solution or wait for the native implementation. Do you have a rough estimate of whether this feature might land by the end of this year, or is it too early to tell at this point? Even a high-level indication would help me with planning.

[DaZuiZui]

I have a working prototype following the plugin-based direction proposed above. The implementation is split into a very small ECharts core change and an independent export-toolbox package:

1. ECharts core exposes registerToolboxFeature(name, ctor) through the existing echarts.use() installer API, and exports the ToolboxFeature class/types from echarts/core. This is the missing stable hook that lets an external package register toolbox.feature.exportData without adding exporter code or dependencies to the core bundle.
2. The independent package registers an exportData toolbox feature and also exports exportChart(chart, options). Both paths call the same exporter registry, so the UI and programmatic APIs cannot diverge.
3. Data input stays explicit: callers provide either table or getTable(chart). getTable is evaluated when the user clicks the button, so applications can export a fresh snapshot. This avoids trying to reverse-engineer arbitrary dataset / transform / encode / multi-series options in the first version.
4. CSV serialization is dependency-free and supports array rows, object rows, inferred or explicit columns/headers, configurable delimiter/line ending/BOM, RFC-style quote escaping, and spreadsheet-formula-injection protection by default.
5. download: false returns the generated result without touching DOM APIs, which makes the programmatic API usable in SSR and tests.
6. Other formats can be added independently with registerExporter('pdf' | 'xlsx' | ..., exporter), without changing ECharts core.

Proposed usage:

echarts.use([ToolboxComponent, ExportToolbox]);

chart.setOption({
  toolbox: {
    feature: {
      exportData: {
        format: 'csv',
        filename: 'sales',
        getTable: () => [
          { month: 'Jan', sales: 120 },
          { month: 'Feb', sales: 132 }
        ]
      }
    }
  }
});

// Same implementation, programmatic entry:
await exportChart(chart, {
  format: 'csv',
  filename: 'sales',
  table: [['month', 'sales'], ['Jan', 120]]
});

I also added a core registration unit test, public DTS coverage across the supported TypeScript versions, and serializer/registry tests for the plugin. If this API split and naming look right to the maintainers, the core hook and the independent package can be submitted separately so their release cycles remain decoupled.