tyn1998 commented on issue #16152: URL: https://github.com/apache/echarts/issues/16152#issuecomment-1207182380
# [8.6] A Possible Interface for This Feature Hi, guys! I have come up with an interface to allow users to implement multi-level drill-down/up easily and intuitively. The new interface will be compatible with the old way of using `groupId` to trigger a universalTransition, which means the new design is not a breaking change. ## The possible new interface: `childGroupId` Good news! There is only a single new key introduced to the new interface design and that is `childGroupId`. We alreay have `groupId`, right? A `groupId` can decide which group the dataItem belongs to, and if no `groupId` is specified, echarts will use `series.dataGroupId` as the dataItem's `groupId`. If 1/N oldDataItem's `groupId`is matched with 1/N newDataItem's `groupId` and with `universalTransition` enabled in both sides, the universalTransition will happen. Now, with `childGroupId`, you can specify it in dataItems to introduce a **real** hierarchical relationship. As the three hierarchical data show below, if a logical parent's `childGroupId` is equal to his/her logical child's `groupId`, they are regarded as being matched. In a set of hierarchical datas, the items' `groupId`s of the root data can be whatever or `undefined` and the items' `childGroupId`s of the "childest" data can be ignored too. The rest dataItems are linked logically by many pairs of `childGroupId` and `groupId`. | root | child | grandChild | | --- | --- | --- | |  |  |  | I mention the word "logical" several times to stress that the hierarchical relationship is only in our brain, for echarts, however, it does not identify the hierarchical relationship directly. It only see an old option and a new option and that is a hurdle I should clear first when I try to implement the feature. ## How to match `childGroupId` with `groupId` in code? | parent2child | child2parent | | --- | --- | |  |  | Assume that we are setting option from `root` to `child`. We know the old option is a "parent" and the new option is a "child", so we will compare `oldDataItem.childGroupId` with `newDataItem.groupId`. If they are equal, they are matched. What if we set option from `child` to `root`? Yes, we will compare `oldDataItem.groupId` to `newDataItem.childGroupId` to check if they are metched. It is so natural since we have a context of the hierarchical relationship in our mind. But echarts has no idea about which two keys it should compare because it does not know whether it is a "parent2child" setOption or a "child2parent" setOption. The solution I figured out is to decide the direction ("parent2child" or "child2parent") before `createKeyGetter()`, so in `createKeyGetter()` I can return the right key accordingly. For example, if `isOld === true`and `direction === 'parent2child'`, the returned key should be the value of `childGroupId`. While if `isOld === true`and `direction === 'child2parent'`, the returned key should be the value of `groupId`. Then, how I decide the direction? I will explain it later since it is too detailed. ## Others Please review my design for the interface of the new feature and if anything is wrong, feel free to adress me, thanks! -- 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]
