/ echarts Public
[5.0] [FEATURE] Remove component #12987
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge.
This pull request is in the type of:
What does this PR do?
Provide a new mode in
setOptionto support removal of some components.
After this PR, there are three mode about component update:
Most common used. The existing component will NEVER be removed.
The components declared in the input
optionwill be merged to some existing component by
index, or create new component if not able to be merged.
Replace all of the existing models with the new option, no state in models are kept.
The specified component (by
mainType) will be performed
replaceMerge, others will go with
Within the scope of a certain
mainType, the existing components will be merged with the new component declarations (in the input
option) only if they have id matched. All of the other existing components will be removed, and all of the other new components will be created on the empty
By the mechanism of
replaceMerge, we can remove a certain
mainTypeof components, or totally replace them with new components, or partially replace and partially remain.
See show case below for details.
Others fix and enhancement
xAxisIndex: 'all', referencing none axis by like
setOption. Now make it works on multiple time of
getOption). The state of the chart instance (like zoom state) will be reproduced.
Previously, the interaction state can not be kept if using
At present, the interaction state can be kept when using
At present, we are able to add and remove coordinate systems freely, and make dataZoom controls axis as expected. That might be some basic of storytelling demo. Previously, there were several bugs not also about coord sys but also about toolbox and dataZoom:
At present, series can be removed, while other not related series and components keeping their state:
Previously, there is a timeline bug when different time tick has different number of series (series can be added but can not be reduced):
At present, series can be removed in timeline:
Related test cases
Whether to change the component index after other components removed?
The questions is: whether the
componentIndexof should be changed after some component removed via
There has been some discussion about it, but not clear at that time because not touch the code enough then.
After trying to implement it, found something more clearly:
Suppose there has been component: [A, B, C, D].
That means: A.componentIndex === 0, B.componentIndex === 1, ...
replaceMergemode to remove B, C and add X.
Strategy of change the index
The final component indices may be like: [A, X, D], or it also may be [A, D, X].
There might be no easy and intuitive way to make users aware what the final indices are.
Strategy of keep the index
The final component indices may be like: [A, X, -, D], or it also may be [A, -, -, D, X].
Users are also not easy to know what D.componentIndex is. But at lease, users can know that the existing A and D do not change their componentIndex. Thus the "index reference" (like xAxisIndex, yAxisIndex) in option about A and D will not be broken.
So we can probably found that:
(1) In either of the two strategy, users are probably not able to know clearly what the final indices like if the second
setOptionboth added and removed something. Therefore, if users meet this kind of scenario, it's not a good idea to use index to reference components. On the contrary, using id should be recommended.
(2) [strategy_keep_index] do not break the previous "index reference".
(3) [strategy_change_index] might make the code more brittle, because it forbids any of the persistence (like hash map key) are relevant to
seriesIndex(because it might be changed). It not easy to always ensure that and might not easy to be found in test stage.
So finally, chose [strategy_keep_index]. And in this strategy, the "hole" might exists. New components are first to fill the hole.
TODO: Do we need
notMerge: ['series']seems more intuitive than
replaceMerge: ['series']when just need to totally replace series.
And if we only want to reset a type of components,
if we use
replaceMerge: ['dataZoom'], we need to make sure
idis not specified or change a different
notMerge: ['dataZoom']is easy a bit.
TODO: about the "Restore" feature
"Restore" feature means the
toolbox.feature.restoreand the action "restore".
Previously the implementation of "restore" is not a complete solution, because after the second
setOption, in some case it can not restore to exactly the original state.
The reason is, the original requirement expect that "only restore the user interaction" but "do not restore the
setOptionis always used to update the data).
If these things below happen one by one:
After "restore" click, we expect the final state exactly the same as:
The previous implementation is temporary and not totally correct and not easy to be enhanced to support the new feature "replaceMerge".
So we do not support it at present and remove the support of "restore" after the second
That is a TODO .
Related issues: #6202 #4356 #4033 #8246 #3002