[Feature] coordinate system API enhancement
- Dominant language
- TypeScript
- Stars
- 67.3k
- Forks
- 19.8k
- Avg merge
- 11d 14h
- Merged PRs (30d)
- 8
Description
## Background
Currently `chart.convertToPixel` `chart.convertFromPixel` `chart.convertToLayout` may not be suitable
for some extremely performance-sensitive scenarios (such as, handling massive amounts of data),
since it performance "find component" every time.
Additionally, they are not friendly to the nuances between coordinate systems.
+ TS: they cannot provide specific TS types according to each coordinate system.
+ Coordinate system may have they unique API.
## A more ideal API design might be
```ts
const coordSys = chart.findCooridnateSystem('coor-sys-type-identifier', finder);
// And the specific TS type of coordSys can be determined.
for (...) {
const point = coordSys.convertToPixel(value);
}
// Alternative, add opts and out for performance-sensitive case.
const opt = {...};
const outPoint = [];
for (...) {
coordSys.convertToPixel(value, opt, outPoint);
}
// Coordinate system specific API.
coordSys.otherCoordSysNuancedAPI();
```
## Implementation concerns
But this design requires:
+ Abstraction for every coordinate system.
+ Including axis alone, i.e., `convertToPixel({xAxis: 0}, 123)`, which is supported in `Grid.ts`.
+ Also need to **prevent unnecessary exposure of internal method and properties**. Backward compatibility is essential, and exposing too much of internal data structures to users creates a heavy maintenance burden.
+ Also need to ensure the lifetime of return instance from `const coordSys = chart.findCooridnateSystem('some-type-identifier', finder);` is properly managed; it should remain valid as long as the corresponding model exists, but become obsolete once the model is disposed (e.g., by `setOption({notMerge: true})`).
+ Prevent from introducing too much complexity.
---
Therefore I'm not sure whether we need that yet.
Contributor guide
Assessment
This issue has not been assessed yet.