-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Add layout.subplots
to enable (x|y) hover effects across multiple cartesian and splom suplots sharing one axis
#6947
Conversation
layout.hoversameaxis
to enable hover effects across multiple cartesian suplots sharing one axis
LGTM @archmoj . Re: API design -- I do think this should be its own property, the way you have it, rather than adding more hovermodes, since adding so many keywords in the hovermode starts to get pretty unwieldy. I'm not sure the name Maybe something like |
Thanks @emilykl for the feedback. Also it may be possible to add another option to this feature so that the hover show points in suplots above & below (or left & right) even if they are NOT linked to the same axis. Perhaps instead of the cc: @alexcjohnson |
layout.hoversameaxis
to enable hover effects across multiple cartesian suplots sharing one axislayout.hoverthrough
to enable hover effects across multiple cartesian suplots sharing one axis
layout.hoverthrough
to enable hover effects across multiple cartesian suplots sharing one axislayout.hoverthrough
to enable hover effects across multiple cartesian and splom suplots sharing one axis
How about |
layout.hoverthrough
to enable hover effects across multiple cartesian and splom suplots sharing one axislayout.subplots
to enable (x|y) hover effects across multiple cartesian and splom suplots sharing one axis
I like this. |
|
||
afterEach(destroyGraphDiv); | ||
|
||
it('splom hoversubplots: *axis*', function() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Splom has an additional constraint that I don't believe is tested here, and I suspect is broken: If the main hovered point has the same coordinate as some other points, every point we show on other axes should be the same item on other axes. For example, let's say we have this data:
dimensions: [{
values: [1, 1, 1, 1] // hover on a subplot where this is the x axis, so all points are in a vertical line
}, {
values: [1, 2, 3, 4] // put the mouse at y=2 on this subplot
}, {
values: [1, 2, 3, 4] // we should see y=2 hovered in this subplot as well
}, {
values: [1, null, 3, 4] // no hover points should be displayed on this subplot
}]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This actually makes me wonder if we should use pointNumber
as a tiebreaker (and possible performance improvement) for generic multi-trace hover, either same or different subplots: After we've found the primary hovered point, for each additional trace we examine, see if (a) the data arrays have the same length as those for the primary point, (b) the data point with the same index satisfies the criteria to be another point in the hover set (ie the x value matches, for x or x unified modes). If so, use it and don't bother searching the whole trace. If either of those conditions is not met, assume the points in these traces aren't supposed to correspond 1:1 to each other and continue with the way we do this today.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch for splom
.
It is addressed in d9aea4b.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💃 lovely!
would typescript stubs get updated for this? Current latest:
|
Resolves #4755 and resolves #2114.
@plotly/plotly_js
TODO:
hovermode
options e.g.'x all'
,x all unified
,y all
andy all unified
instead? --> No.