apache / apache/echarts

[Feature] option for levels radius % to depend on sunburst radius instead of viewport

Open
#20,379 0 comments 0 reactions 0 assignees View on GitHub
en new-feature pending
Dominant language
TypeScript
Stars
67.3k
Forks
19.8k
Avg merge
11d 14h
Merged PRs (30d)
8

Description

### What problem does this feature solve?

Sunburst [levels.radius](https://echarts.apache.org/en/option.html#series-sunburst.levels.radius) could be defined in pixels or percentages of viewport size. Both options make levels' size **static** - [Demo](https://echarts.apache.org/examples/en/editor.html?c=sunburst-simple&code=MYewdgzgLgBAJgQygmBeGBtAUDGBvHXGMBAWwFMAuGAcgHEAnBMOABwRoBpDdgALAJYAbOA3Jhq2IkQLTpJCtRoBVMMCHkYAGXIguPOQDcEQgK5UYARgCs3OUX7DR4yQfuz7chRZoBhEKYQAmAwAFIIwADW-p5GJubUAExucgC-drH4KfbeSv6BwTAAsggMAJ4xmbjGZha22XKOImISmA3u7Z65tOFREOCVVdI1CTDJQ0SpnbgAup3pnR5V3X4BQSEAQuKDmSMWACzzDXP2Cx2xKwBiSHzkDDvD8RaWAAwZ9k3OrVKZS5krRXID08e2o1nm708fwuZB8GwYICgtwYMAACuQoHdgfZQVYjrETmkDISFjMANxYUCQWAaQzkIQQdAYGAAehZMFKmgApDAQAAzGCGATkADurBADFgQQAXuROMREbyBRBTGAAEamBjQGAy8iEPDpXBsmDBIVBNUaGDAcSYlFwRH6mBMOACQKUDA0F5crg0SyWb0zeUCTGkADKUDKGkoeFAQgllBorGC0VSMENbPoTBY7Bojudrog7t9iW9nBoiQAzAGgyHw5GqDGQHGGAmk2AU2msOSsCBWFABOA0FlcBA7sLC5g_hHWD4VerNdAuE6EC63ZhPaXaNYvTRAwZEMhIbT6RBCKk5qkKaOoAAVAQUAJQAAUAA80AA-Ye8vsDsAAOlHBhxwwF4Zj_fNAiHD0d3lGgAA4d27XBSDKXw-FKKAAIxAB5H9wCfXt-3AABKMlWRZeUoAYcxSKwQ1EgYxJSKAA).

A new convenient and responsive option would be to allow percentages to depend on **current sunburst radius**.
This will allow a command like ```myChart.setOption({ series: [{ radius: [0, '80%'] }] });``` to correctly scale the entire chart.
Also helps with zooming sunburst charts since _roam_ property is now missing. See #19370

### What does the proposed API look like?

```
levels: [
{ radius: '20%' }, // percentage of sunburst radius
{ }, { }, // these 2 levels will adapt to fit in remaining space (2 * 5% = 10%)
{ radius: '70%' }, // percentage of sunburst radius
]
```
At present, _radius_ is defined as a number or an array, so adding a _string_ type wont break existing code.
This also avoids adding a new option property.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.