Skip to content

feat(tree): support configurable radial level spacing - #21800

Draft
Bilge wants to merge 2 commits into
apache:masterfrom
Bilge:feat-tree-radial-level-gap
Draft

Bilge wants to merge 2 commits into
apache:masterfrom
Bilge:feat-tree-radial-level-gap

Conversation

@Bilge

@Bilge Bilge commented Oct 20, 2026 •

Copy link
Copy Markdown
Contributor

Brief Information

This pull request is in the type of:

  • bug fixing
  • new feature
  • others

What does this PR do?

Adds series.tree.radialLevelGap to configure distances between successive radial tree levels independently of the layout box.

Fixed issues

New option; no issue is closed by this draft.

Details

Before: What was the problem?

Radial tree layout divides the available radius equally between all visible depth levels. Changing the layout box scales every gap together. A hidden data root therefore reserves the same radial distance as every other level, leaving excessive empty space in dense two-level hierarchies; applications cannot reduce that first gap independently of the distances required by outer labels.

After: How does it behave after the fixing?

series: [{
    type: 'tree',
    layout: 'radial',
    radialLevelGap: [40, 100],
    data: [treeData]
}]
  • A number sets the CSS-pixel distance between node centres at every successive depth.
  • An array sets successive distances: index 0 is the actual data root to its children, not ECharts' internal virtual root.
  • Missing array entries retain the existing automatic per-level distance.
  • An unset option or an empty array preserves the existing coordinates exactly.
  • The data root remains at radius 0. Node angles, sibling separation and orthogonal layout are unchanged.
  • Explicit distances may exceed the available box; they are not silently fitted or clamped. Values are finite and non-negative.

Scalar distances use direct multiplication. Configured arrays calculate cumulative radii once per layout; the default path allocates no radius array. Polar radii and Cartesian coordinates use the same values, so existing curves and transitions continue to use coherent geometry.

Document Info

  • This PR doesn't relate to document changes
  • The document should be updated later
  • The document changes have been made in apache/echarts-doc#xxx

Option semantics are documented on TreeSeriesOption.radialLevelGap; test/tree-radial.html includes a paired default/custom example and explains indexing, units, partial arrays and resize behavior. This draft proposes the API before a separate website-option documentation change.

Misc

Security Checking

  • This PR uses security-sensitive Web APIs.

ZRender Changes

  • This PR depends on ZRender changes (ecomfe/zrender#xxx).

Related test cases or examples to use the new APIs

  • test/ut/spec/series/tree.test.ts: eight real-chart tests cover default and empty-array compatibility, scalar/zero/oversized gaps, independently configured depths, unequal branches, partial arrays, resize and option updates, collapse/re-expansion, all orthogonal orientations and root-only trees. Assertions verify Cartesian geometry as well as stored radii and exact angular compatibility.
  • test/tree-radial.html: paired default/custom multilevel example, exercised in headless Chrome. The custom example produces radii 0/90/115/160 with identical angles to the default.

Verification:

TZ=UTC npm test -- --runInBand --coverage=false
npm run build:lib
npm run checktype
npm run lint:nocache

All 27 unit suites / 202 tests pass, exported declarations build, type checks pass and uncached lint passes. Before the implementation, four new geometry cases failed against the unchanged source because requested distances were ignored. The existing local-time test depends on the host's historical timezone offset, so the full suite was also run with an explicit UTC environment; no time-test code was changed.

The option was also exercised in a real dense radial tree: 103 labels, 93 visible parent-child edges, no initial label overlap or canvas clipping, with actual drag, wheel zoom and tag navigation checked. Label styling/packing for that application is not included in this library PR.

Merging options

  • Please squash the commits into a single one when merging.

Other information

This branch contains only the new option, layout implementation, geometry regressions and visual example. It does not include the separate dataZoom step-line patch carried by the fork.

@echarts-bot echarts-bot Bot added the PR: awaiting doc Document changes is required for this PR. label Oct 20, 2026
@echarts-bot

echarts-bot Bot commented Oct 20, 2026

Copy link
Copy Markdown

Thanks for your contribution!
The community will review it ASAP. In the meanwhile, please checkout the coding standard and Wiki about How to make a pull request.

Please DO NOT commit the files in dist, i18n, and ssr/client/dist folders in a non-release pull request. These folders are for release use only.

Document changes are required in this PR. Please also make a PR to apache/echarts-doc for document changes and update the issue id in the PR description. When the doc PR is merged, the maintainers will remove the PR: awaiting doc label.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

PR: awaiting doc Document changes is required for this PR. size/S

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant