feat(visualMap): able to set the 'dimension' to an array

[Justin-ZS]

Brief Information

This pull request is in the type of:

• bug fixing
• new feature
• others

What does this PR do?

able to set the 'dimension' to an array.
item in array will be mapped to target series by index.
official demo

{
  // no series index
  dimension: [1,2,3] // seriesIndex: 0 -> 1, 1 -> 2, 2 -> 3
}
{
  // no series index
  dimension: [1,2] // seriesIndex: 0 -> 1, 1 -> 2, 2 -> 2 missmatched series will use the last dimension
}
{
  seriesIndex: [1, 2]
  dimension: [2,3] // seriesIndex: 1 -> 2, 2 -> 3
}

Fixed issues

#20662

Details

Before: What was the problem?

#20662

After: How does it behave after the fixing?

able to set the 'dimension' to an array.
item in array will be mapped to target series by index.

Document Info

One of the following should be checked.

• 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

Misc

ZRender Changes

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

Related test cases or examples to use the new APIs

N.A.

Others

Merging options

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

Other information

[echarts-bot]

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.

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.

[Ovilia]

I don't think it's intuitive to use dimension: [1,2] to represent seriesIndex: 0 -> 1, 1 -> 2, 2 -> 2. Instead, it's more like using both dimension 1 and 2.

I think the problem of #20662 should be best solved using the third demo @MatthiasMert gave. I would suggest closing this PR unless a more solid reason is given. Thanks for your contribution anyway.

[Justin-ZS]

I don't think it's intuitive to use dimension: [1,2] to represent seriesIndex: 0 -> 1, 1 -> 2, 2 -> 2. Instead, it's more like using both dimension 1 and 2.

I think the problem of #20662 should be best solved using the third demo @MatthiasMert gave. I would suggest closing this PR unless a more solid reason is given. Thanks for your contribution anyway.

Using the same visualMap on 2d dataset requires the dataset to be splitted looks overkill.
dimension: [1,2] cannot be explained as using both dimension 1 and 2 since one series can use only one dimension
using both dimension 1 and 2 is technically impossible, unless you choose to provide a function to aggreagte multiple values

[Ovilia]

It's true that using both dimension 1 and 2 is technically impossible. Even though, it's misleading to provide such API design. Again, I would suggest using the 3rd solution or avoid using dataset in your case. Adding a new feature should take a lot of things into consideration so I would say it's not quite a good design of API unless a better plan is proposed.

[Justin-ZS]

It's true that using both dimension 1 and 2 is technically impossible. Even though, it's misleading to provide such API design. Again, I would suggest using the 3rd solution or avoid using dataset in your case. Adding a new feature should take a lot of things into consideration so I would say it's not quite a good design of API unless a better plan is proposed.

Again, the suggested workaround (splitting the dataset) is unacceptable in my use case.

I understand your concerns about the API design.
I do think this PR is a simple and clear solution for similar cases.
We can provide detailed document to clarify the correct uasge.

Even if user is misled into thinking it as using both dimension 1 and 2, user will still use the numeric dimension unless they want to map multiple dimensions.
Then, they will find the correct usage through document or just a few attempts.

if you insist, I will keep this PR open until a better solutiion is proposed.

[Ovilia]

Why is the suggested workaround (splitting the dataset) unacceptable?

[Justin-ZS]

Why is the suggested workaround (splitting the dataset) unacceptable?

It requires huge refactoring (tooltip, axis. series and so on) and maintaining two implementations.
And the splitted datasets may cause other limitations or bugs.
As a workaround for now, I added the same visualmap for each series and only show the first controller.
When selection changes, use setOption to sync the state cross all visualMaps.
But the hoverLink interaction cannot be synced.

[Ovilia]

I don't think it should require huge work to refactor from dataset to not. And besides, you can try with AI to help.