DaZuiZui commented on issue #21693:
URL: https://github.com/apache/echarts/issues/21693#issuecomment-5102837376
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:
```ts
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
