Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VictoryVoronoiContainer with VictoryBar inside VictoryGroup gives inconsistent grouping in tooltip depending on bar values #2847

Open
2 tasks done
olignyf opened this issue Apr 2, 2024 · 6 comments
Labels
Issue: Accepted The submitted issue has been confirmed by the Victory core team Type: Bug 🐛 Oh no! A bug or unintentional behavior

Comments

@olignyf
Copy link

olignyf commented Apr 2, 2024

Is there an existing issue for this?

  • I have searched the existing issues

Code of Conduct

  • I agree to follow this project's Code of Conduct

Victory version

36.6.8

Code Sandbox link

https://codesandbox.io/p/sandbox/victory-starter-forked-xczy4h?file=%2Fsrc%2FApp.tsx

Bug report

I've been trying to workaround this but to no avail so I'm reaching out for an improvement request or help.

My end goal is to have consistent tooltip on grouped bar graph like below:
Surely a new boolean prop to dictate the tooltip grouping behavior could resolve this.

frame graph grouped tooltip

Steps to reproduce

Check the sandbox.
Hover over the various bars.
Having VictoryBar inside VictoryGroup.
Some bars with the same value within a group
Some bars with all distinct values within a group.
The tooltip behavior is inconsistent.

Expected behavior

When hovering over a group of bar, having a consistent grouping behavior. 
Maybe always show a single tooltip even if repeated values are found.
Like this we can build up our own grouped tooltip with the commented code in my sandbox or keep the behavior of a single bar per tooltip.

Actual behavior

When bars in a group have the same value, they get grouped in the same tooltip. 
When a bar value is unique in the group, it prints a single element tooltip. 
This cause inconsistent behavior that's impossible to customize.

victory bug tooltip 1
victory bug tooltip 2
victory bug tooltip 3
victory bug tooltip 4

Environment

It's a nice sunny spring day outside, 49°F
@olignyf olignyf added the Type: Bug 🐛 Oh no! A bug or unintentional behavior label Apr 2, 2024
@olignyf
Copy link
Author

olignyf commented Apr 3, 2024

It seems related to #1925

@olignyf olignyf closed this as completed Apr 3, 2024
@olignyf olignyf reopened this Apr 3, 2024
@olignyf
Copy link
Author

olignyf commented Apr 3, 2024

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

@carbonrobot carbonrobot added the Issue: Accepted The submitted issue has been confirmed by the Victory core team label Apr 4, 2024
@carbonrobot
Copy link
Contributor

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
Copy link
Author

olignyf commented Apr 4, 2024

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 }}

@carbonrobot
Copy link
Contributor

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.

image

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
Copy link
Author

olignyf commented Apr 5, 2024

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
victory trigger 1
then I get the two bars with same value grouped, even though they are not next to each other.
victory-trigger-2c
Which line of code cause that grouping of same value? Maybe I can help with a simple PR.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue: Accepted The submitted issue has been confirmed by the Victory core team Type: Bug 🐛 Oh no! A bug or unintentional behavior
Projects
None yet
Development

No branches or pull requests

2 participants