VictoryVoronoiContainer with VictoryBar inside VictoryGroup gives inconsistent grouping in tooltip depending on bar values about victory

[carbonrobot]

A few details which are important here...

The Voronoi container uses an x-y coordinate and radius to determine the match. That it triggers on the X axis is purely coincidental. It's only occurring because the values are so low that the {x,y,r} circle finds a match within its bounds.

Here is a diagram that helps visualize this better. We take the cursor position and draw bounds of a circle with radius r at position x,y. If a data point falls within these bounds, it triggers a tooltip to be shown for all data points within the bounds.

For the case of the 4.0 x value bars, two of the values fall within the same radius bounds, so they are shown in the same label. It's unclear how we could handle this differently.

• Setting the radius property to a lower value makes it very difficult to trigger correctly with the mouse.
• We could add an option to never group labels, but that would require us to show multiple tooltips for every value that falls within the radius which is also not ideal. In your use case, it would show 3 overlapping tooltips.
• We could build new functionality that always groups everything
• We could build a specialized container for bar graph grouping

I will try to explore some other options

[olignyf]

It seems related to #1925

[olignyf]

Adding labels={(d) => d.datum.y} and labelComponent={<VictoryTooltip/>} doesn't fix the issue.

[carbonrobot]

The Voronoi container is designed to group the tooltips. Would it work for you to just use simple tooltips?

https://codesandbox.io/p/sandbox/victory-starter-forked-6mv73c

[olignyf]

Thanks for the reply! The workaround of using simple VictoryTooltip on the individual bars makes it consistent but we loose the ability to trigger the tooltips by hovering on the x-axis labels. Also the target area is smaller you have to be directly on a bar to open the tooltip where before we could hover even on the white space above and around the bars and it would open the tooltips. Also in the case of some groups of bars having small values like 1 and zeros, it's hard to trigger the tooltip (and impossible in the case of the value zero). The target areas of VictoryVoronoiContainer was much better. I think the best would be a new boolean prop on VictoryVoronoiContainer to dictate the grouping behavior.

Also note in my sandbox example the bottom padding needed to be adjusted from 10 => 30 for the x-axis labels to show. I made it too small. I corrected it.
padding={{ top: 100, bottom: 10, left: 40, right: 40 }}
=>
padding={{ top: 100, bottom: 30, left: 40, right: 40 }}

[olignyf]

Some thoughts that comes to mind:

• The coincidental trigger on the X-axis is actually useful so it would seems a solution within the Voronoi container that provide this radius is a good way to go if understand correctly.
• Regarding "We could add an option to never group labels, but that would require us to show multiple tooltips for every value that falls within the radius which is also not ideal. In your use case, it would show 3 overlapping tooltips." I don't understand. Right now it only groups labels within a group that have the exact same value. Let say I have two values at 99, if I just tweak one to be 99.0001 it will cause them to have non-grouped tooltips. There must be a line of code that matches those same values to group them? Then it must be easy to turn it off.
• "We could build new functionality that always groups everything". If it combines all the bars within a that would also work. But they would need to be join('\n'). The solution of having them individual would leave the joining on the user side which might be more flexibility (better). But it would be an acceptable resolution anyhow.

If I hover at the place circled

then I get the two bars with same value grouped, even though they are not next to each other.

Which line of code cause that grouping of same value? Maybe I can help with a simple PR.

Thanks!