Hide hover and spike modebar buttons in plotly.js v2 by default and add config options to bring them back in #5654

archmoj · 2021-05-11T20:58:36Z

Addressing #5642.

After this PR, hover and spike line buttons would not be visible by default.
To add any of those back one could provide the name of the button via config.modeBarButtonsToAdd similar to what we do for shape drawing buttons.

Perhaps we should unify, simplify and nonCamelify some of these names too in v2?
hoverCompareCartesian
hoverClosestCartesian
hoverClosestGl2d
hoverClosest3d
hoverClosestGeo
hoverClosestPie
toggleHover
toggleSpikelines

update:
the pre-defined buttons names are simplified and lowercase as follow:
hovercompare
hoverclosest
togglehover
togglespikelines

In addition one could use v1hovermode to bring back v1 hover buttons.

@plotly/plotly_js

nicolaskruchten · 2021-05-11T21:01:27Z

I would make these all case-insensitive.

alexcjohnson · 2021-05-11T21:45:21Z

As discussed this morning with @archmoj:

Ideally we would collapse all the hovermode buttons to two, each with consistent behavior:

hovercompare: If there are cartesian subplots and hovermode='x' or 'y' it's selected, otherwise it's deselected. If you click on it while it's deselected, it sets hovermode to 'x' (or 'y' if we just have horizontal bars). If you click on it while it's selected, it sets hovermode to false
hoverclosest: If hovermode is 'closest', and any subplots that have their own hovermode it's also 'closest', it's selected; otherwise it's deselected. If you click on it while it's deselected it sets hovermode in layout and any relevant subplots to 'closest'. If you click on it while selected it sets those same attributes to false.

In principle we should be able to do the same with the various type-specific zoom, pan, and reset buttons: define behavior for them that doesn't depend on which subplots are present, so users can just think about which functionality they want present, not which specific functions are attached to those icons.

That's probably not in scope right now though, as it'd be a bit of a project. But that seems like what we'd need to do to make these options really user-friendly.

nicolaskruchten · 2021-05-11T21:52:14Z

Hmm seems like we'd really need per-subplot modebars to do this right then. We can discuss for v4 ;)

alexcjohnson · 2021-05-11T22:01:29Z

Oh I don't think we want per-subplot... except maybe for zoom in/out, but that's really better handled by other more specific interactions anyway. It's just that if you have several subplots with inconsistent modes, neither of the buttons would start out selected, and the modes would be made consistent after you click one of the buttons.

But yeah, v3 or v4 🙈

archmoj · 2021-05-12T18:50:54Z

Right now having two buttons for compare and closest hover options is rather confusing.
In addition, this does not support unified hover options!
How about having one non-binary button for hover togelling between n different options?

nicolaskruchten · 2021-05-12T19:38:19Z

No need to keep exploring various options in the short term now that these are off by default :)

alexcjohnson · 2021-05-13T15:35:28Z

src/components/modebar/manage.js

+        if(hoverGroup.indexOf(a) !== -1) {
+            enabledHoverGroup.push(a);
+        }
+    };


So what you're saying is, we still calculate the hover entries you would have gotten, back in 1.x when we included them by default, and in 2.x you won't get them by default but you'll be allowed to re-include any of those exact buttons but no others.

I guess it makes sense to restrict to only the buttons we know will work, but as a user it may be hard to figure out what those buttons are in any given case. For example Sankey gets ['hoverClosestCartesian', 'hoverCompareCartesian']? And some multi-type plots just get ['toggleHover'] but others get something more specific?

What if we accept a special buttonsToAdd value 'hovermode', that copies all of hoverGroup into enabledHoverGroup - ie to get back 1.x behavior no matter what traces you have you can just use that one special value?

What if we accept a special buttonsToAdd value 'hovermode'

this sounds like a good solution to me.

maybe v1hovermode or something to clearly identify this as "the v1 behaviour" ?

So what you're saying is, we still calculate the hover entries you would have gotten, back in 1.x when we included them by default, and in 2.x you won't get them by default but you'll be allowed to re-include any of those exact buttons but no others.

Exactly.

What if we accept a special buttonsToAdd value 'hovermode', that copies all of hoverGroup into enabledHoverGroup - ie to get back 1.x behavior no matter what traces you have you can just use that one special value?

It is doable but at the same time rather confusing (and perhaps hard to maintain) as the v1 hoverGroup does include spike options too. Plus in that case we may restrict users to only include all of those buttons but not some?

Right, if you want some subset of the v1 behavior you have to figure out the specific options you need and specify them explicitly.

Good point re: spikes. 'togglespikelines' is pretty simple and easy to document; so let's have 'v1hovermode' give you just the hovermode buttons - ie everything in hoverGroup except toggleSpikelines if it's there.

OK.
How about allhovermodes instead of v1hovermode?
Later on the road we may want to add extra buttons e.g. for unified hover options and having v1 would make it difficult to add those.

If we call it allhovermodes it's wrong until we add unified. And unified is more a decision chart developers will make, whereas compare vs closest has times it's useful to viewers (mainly for charts that the developer didn't explicitly specify the best hovermode) so I don't see much need to add a button for unified.

If we call it allhovermodes it's wrong until we add unified

Yes. I would favour v1hovermodes as it's clear that this is simply brining back the old mode without making any additional promises/implying anything else about "all" anything :)

Added in f4e6120.

alexcjohnson

💃 LGTM!

@andoks

@andoks * plotly.js: add missing hover modebar button strings supported by modeBarButtonsToAdd Add the missing hover-related default-button strings as supported in [plotly.js 2.12][]. Of particular importance is perhaps the v1hovermode which restores the default modebar buttons from plotly v1 (see [PR: Hide hover and spike modebar buttons... #5654][]). Also add a test for using the values in modeBarButtonsToAdd [plotly.js 2.12]: <https://github.com/plotly/plotly.js/blob/v2.12.0/src/components/modebar/manage.js#L235> [PR: Hide hover and spike modebar buttons... #5654]: <plotly/plotly.js#5654> * plotly.js: allow mixing predefined and custom modebar-buttons Also test that passing both predefined button strings and custom button structs works

archmoj added 3 commits May 11, 2021 14:55

drop hover and spike modebars

b19d960

add hover and spike modes to extra modes that could be enabled

992352b

adjust tests

f7d5a3a

archmoj added status: has TODOs labels May 11, 2021

archmoj added this to the NEXT milestone May 11, 2021

archmoj removed the status: reviewable label May 12, 2021

archmoj added 2 commits May 12, 2021 18:01

enable hover modebars using simplified strings

74649d0

use lowercase for exposed hover button names

3602a51

archmoj added status: reviewable and removed status: has TODOs labels May 12, 2021

archmoj added 2 commits May 12, 2021 18:16

bring back and adjust two noHover tests

cd6c5a1

accept uppercase and camelCase strings modebar button strings

2d4bc78

archmoj requested a review from alexcjohnson May 13, 2021 14:58

alexcjohnson reviewed May 13, 2021

View reviewed changes

add v1hovermode option

f4e6120

alexcjohnson approved these changes May 14, 2021

View reviewed changes

archmoj changed the title ~~Revise hover and spike modebar buttons in plotly.js v2~~ Hide hover and spike modebar buttons in plotly.js v2 by default and add config options to bring them back in May 14, 2021

archmoj merged commit 2eca2a6 into master May 14, 2021

archmoj deleted the v2-modebar branch May 14, 2021 12:55

nicolaskruchten linked an issue May 14, 2021 that may be closed by this pull request

v2 modebar changes #5642

Closed

archmoj mentioned this pull request Aug 16, 2021

update documentation about hover modes in buttons #5892

Open

andoks mentioned this pull request Nov 17, 2022

plotly.js: improve plotly modeBarButtonsToAdd type DefinitelyTyped/DefinitelyTyped#63295

Merged

9 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Hide hover and spike modebar buttons in plotly.js v2 by default and add config options to bring them back in #5654

Hide hover and spike modebar buttons in plotly.js v2 by default and add config options to bring them back in #5654

archmoj commented May 11, 2021 •

edited

Loading

nicolaskruchten commented May 11, 2021

alexcjohnson commented May 11, 2021

nicolaskruchten commented May 11, 2021

alexcjohnson commented May 11, 2021

archmoj commented May 12, 2021

nicolaskruchten commented May 12, 2021

alexcjohnson May 13, 2021

nicolaskruchten May 13, 2021

nicolaskruchten May 13, 2021

archmoj May 13, 2021

archmoj May 13, 2021 •

edited

Loading

alexcjohnson May 13, 2021

archmoj May 13, 2021

alexcjohnson May 13, 2021

nicolaskruchten May 13, 2021

archmoj May 13, 2021

alexcjohnson left a comment

Hide hover and spike modebar buttons in plotly.js v2 by default and add config options to bring them back in #5654

Hide hover and spike modebar buttons in plotly.js v2 by default and add config options to bring them back in #5654

Conversation

archmoj commented May 11, 2021 • edited Loading

nicolaskruchten commented May 11, 2021

alexcjohnson commented May 11, 2021

nicolaskruchten commented May 11, 2021

alexcjohnson commented May 11, 2021

archmoj commented May 12, 2021

nicolaskruchten commented May 12, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

archmoj May 13, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexcjohnson left a comment

Choose a reason for hiding this comment

archmoj commented May 11, 2021 •

edited

Loading

archmoj May 13, 2021 •

edited

Loading