Feature: Sankey Link Hover Styling (via link hovercolor attribute)

[TortoiseHam]

Existing Behavior:
When a user hovers over a link in a Sankey diagram, the diagram changes the style of all of the links with the same title. This is useful for tracking what path a particular thing took while it travelled through the diagram. This style change leaves the color the same, but sets the link opacity to 0.4.

Problem:
The current behavior works well when there are only a small number of links, but when dealing with hundreds or thousands of links it becomes impossible to track where an individual link came from. Users have requested a solution to this several times over the past several years:

• https://community.plotly.com/t/feature-request-hover-link-color-in-sankey-graphs/52868
• https://community.plotly.com/t/sankey-link-hover-color/26912
• https://community.plotly.com/t/changing-trace-colors-in-sankey/10691

Proposed Change:
Allow end users to manually specify a link hovercolor attribute separate from the link color attribute in order to customize hover behavior. This makes it feasible to track individual instances across complex diagrams even when there are hundreds of links at once.

Translations:

I'm not sure how to go about translating the new attribute text into all of the other supported languages.

Features, Bug fixes, and others:

Before opening a pull request, developer should:

• make sure they are not on the master branch of their fork as using master for a pull request would make it difficult to fetch upstream changes.
• fetch latest changes from upstream/master into your fork i.e. origin/master then pull origin/master from you local master.
• then git rebase master their local dev branch off the latest master which should be sync with upstream/master at this time.
• make sure to not git add the dist/ folder (the dist/ is updated only on version bumps).
• make sure to commit changes to the package-lock.json file (if any new dependency required).
• provide a title and write an overview of what the PR attempts to do with a link to the issue they are trying to address.
• select the Allow edits from maintainers option (see this article for more details).

After opening a pull request, developer:

• should create a new small markdown log file using the PR number e.g. 1010_fix.md or 1010_add.md inside draftlogs folder as described in this README, commit it and push.
• should not force push (i.e. git push -f) to remote branches associated with opened pull requests. Force pushes make it hard for maintainers to keep track of updates. Therefore, if required, please fetch upstream/master and "merge" with master instead of "rebase".

[TortoiseHam]

@archmoj @alexcjohnson , Any feedback on this hovercolor version of the PR? I went with a grey hover default since it's easy to explain to end user and also significantly easier to implement than dynamically computing the inverse of whatever their existing color array was.

[archmoj]

What's the difference between these two values?

[TortoiseHam]

ah, there isn't. I left that in case y'all wanted to have the default be different between dark mode and light mode, but if it's agreed that grey is ok regardless of bgcolor then it can be simplified

[archmoj]

@alexcjohnson What would you suggest here?

[alexcjohnson]

The issue with grey is it won’t be visible on a grey background. But semi opaque black on a light background and semi opaque white on a dark background makes it visible in all cases

[TortoiseHam]

Do you have specific rgba values in mind for the two cases? I'm happy to swap in whatever defaults you think look good

[alexcjohnson]

Hmm I thought I had written this idea down somewhere but not seeing it now. What I'd propose is to choose the default hover color based on the actual link color (and sometimes the background), either more opaque or (if already opaque) farther from the background:

var darkBG = tinycolor(layout.paper_bgcolor).getLuminance() < 0.333;
var defaultLinkColor = darkBG ? 'rgba(255, 255, 255, 0.6)' : 'rgba(0, 0, 0, 0.2)';
// Lib.repeat is unnecessary AFAICT - provide a single color and it works fine, right?
var linkColor = coerceLink('color', defaultLinkColor);

function makeDefaultHoverColor(_linkColor) {
    var tc = tinycolor(_linkColor);
    if (!tc.isValid()) {
        // does this happen? like can linkColor be an array of numbers or something?
        return _linkColor;
    }
    var alpha = tc.getAlpha();
    if (alpha <= 0.8) {
        tc.setAlpha(alpha + 0.2);
    }
    else {
        tc = darkBG ? tc.brighten() : tc.darken();
    }
    return tc.toRgbString();
}

coerceLink('hovercolor', Array.isArray(linkColor) ? 
    linkColor.map(makeDefaultHoverColor) :
    makeDefaultHoverColor(linkColor)
);

[TortoiseHam]

ah, cool. I've swapped the PR to your proposed defaults

[archmoj]

@TortoiseHam Looking good me and I'd like to include it the next plotly.js minor tomorrow.
Would you be able to address #6864 (comment) ?

[TortoiseHam]

@archmoj , I've incorporated the suggested change to the default values. It'd be awesome to see this go out in the minor :)

[archmoj]

Nicely done.
💃 ====> 💃