dvd233 commented on issue #19601: URL: https://github.com/apache/echarts/issues/19601#issuecomment-6091059275
I reproduced the original fiddle's navigation reset with its 5.4.3 CDN bundle and the 6.1.0 bundle committed at [34f4d92](https://github.com/apache/echarts/blob/34f4d927eafe251f26f63afd3aeefa30f2feba30/dist/echarts.js). I kept the original JavaScript, Canvas renderer and default animation in a local page: clicking Grandpa → Uncle Leo, then the `cat 1` legend item, updates the colors and returns to the full tree. The target node has not been removed. In a separate 6.1.0 SVG fixture with explicit series/node IDs, I also observed: | Update after drilling down | Series model | Result | | --- | --- | --- | | New data values, item colors, or series styling | Retained | A new tree; view returns to its root | | Only `setOption({ title: { text: 'Title changed without series' } })` | Retained | Same reset, despite no series/data in the input | | Same IDs with renamed/reordered nodes, or distinct IDs sharing a name | Retained | Same reset | | `notMerge: true`, or `replaceMerge` with a different series ID | Recreated | Root view | | Removed target or empty data | Retained in normal merge | Root remains valid; no stale node retained | The title-only case also has a concrete source explanation: [backward compatibility preprocessing](https://github.com/apache/echarts/blob/34f4d927eafe251f26f63afd3aeefa30f2feba30/src/preprocessor/backwardCompat.ts) adds `series: []`; normal merging calls `mergeOption({})` on the existing series. That rebuilds the tree, and `resetViewRoot` correctly rejects the old **node object**, even when a new node has the same ID. Simply removing that validity check would retain an obsolete tree node. For an explicit, version-limited restoration experiment in the tested 6.1.0 bundle, I first updated the data normally: ```js chart.setOption({ series: [{ id: 's1', data: nextData }] }); ``` After the update finished rendering, I dispatched the following action, with `target` still present in the incoming data: ```js chart.dispatchAction({ type: 'sunburstRootToNode', seriesId: 's1', targetNodeId: 'target' }); ``` This selected the node from the **new** tree: updated values appeared, and a real click on the center returned to its parent. Renaming/reordering and duplicate names with different IDs worked; a missing target ID did not select a different node with the same name. The action is registered in the implementation but is not listed in the action documentation I checked, so this is an observed option for the tested bundle, not a documented compatibility guarantee. I did not run this restoration matrix on 5.4.3. These are browser diagnostics against the identified bundles, not an upstream test-suite run or a local rebuild of current source. One exact fill-color comparison remains false in the record; the later center-click snapshot contained the requested base color. That comparison is not used to establish the navigation and node-identity conclusions above. What is the intended contract for normal merges: should a still-present explicit, unique node ID preserve drilldown automatically, or should this remain application-managed? That distinction would determine whether to propose a scoped fix or document an explicit restoration approach. -- 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]
