Skip to content

Rewrite legend visibility toggling #2022

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

Merged
merged 6 commits into from
Sep 20, 2017
Merged

Conversation

rreusser
Copy link
Contributor

@rreusser rreusser commented Sep 19, 2017

Legend visibility toggling didn't work at all with groupby, which led to mostly a rewrite. By happenstance, it toggled them as a group, which wasn't really the desired behavior. More problematically though, it also threw lots of Uncaught bad container errors because it really just wasn't accounted for at all. This PR rewrites legend visibility toggling and tries to preserve existing behavior while fixing groupby.

In particular, one tricky case is legendgroup, both toggling and isolating:

regular-trace-toggle

And the other is groupby transforms, both toggling and isolating:

groupby-visibility-toggling

@rreusser
Copy link
Contributor Author

rreusser commented Sep 19, 2017

Oh, and to preempt the question, the answer is, "Yes." 😄

(The legend should say legendgroup, not just group. To not be so cute, the question is: "Does it work with legendgroups spread across different groupby groups?")

combo

@etpinard etpinard added status: reviewable bug something broken labels Sep 20, 2017
case false:
nextVisibility = false;
break;
default:
Copy link
Contributor

@etpinard etpinard Sep 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔪 that default: ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

}

// If not specified, assume visible:
var curState = carr.get(fullTrace._group) || true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this happen?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this === that || true fallback.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. This isn't a great conditional. If it's really fullData, it should always be present and what it means to be. I think I'll just remove this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haha couldn't remove it. Modified it to be a bit more targeted/explicit. The issue is that the container doesn't always have visible defined. "Oh, so just use fullTrace.visible." That didn't work either. Broke some tests. Aimed for some middle ground that passes all the tests.

if(!carr) {
var groupbyIndices = Registry.getTransformIndices(fullInput, 'groupby');
var lastGroupbyIndex = groupbyIndices[groupbyIndices.length - 1];
carr = Lib.keyedContainer(fullInput, 'transforms[' + lastGroupbyIndex + '].styles', 'target', 'value.visible');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

keyedContainer for the win 🏆

By the way, is carr short for container array?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... no need to rename carr to something more explicit, I'm just curious.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it's somewhat of a holdover. It's not great. Maybe kcont?

Copy link
Contributor

@etpinard etpinard Sep 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

carr or kcont, your call.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kcont. ✅

}
carrIdx[fullInput.index] = insertUpdate(fullInput.index, 'visible', fullInput.visible === false ? false : true);
} else {
// false -> false (not possible since will not be visible in legend)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👌


if(hasLegendgroup) {
for(i = 0; i < fullData.length; i++) {
if(fullData[i].visible && fullData[i].legendgroup === legendgroup) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe fullData[i].visible !== false instead of fullData[i].visible would be best, to make things more explicit. It is easy to forget that visible supports two truthy values.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// Compute the clicked index. expandedIndex does what we want for expanded traces
// but also culls hidden traces. That means we have some work to do.
var clickedIndex, isIsolated, isClicked, isInGroup, otherState;
for(clickedIndex = 0; clickedIndex < fullData.length; clickedIndex++) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't clickedIndex simply fullTrace.index?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's see… it might be. I need to think about this just a bit. fullTrace.index vs. fullTrace._fullInput.index vs. fullTrace._expandedIndex obey slightly different rules. I think more often that not the answer was to avoid at all costs needing the index at all. I'll give the above a try.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, good catch. clickedIndex isn't actually used at all, which was the end result of trying to get this right (i.e. don't use it at all). I've removed this code.

@@ -520,52 +570,116 @@ function handleClick(g, gd, numClicks) {

Plotly.relayout(gd, 'hiddenlabels', hiddenSlices);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can return early after Plotly.relayout for pie traces.

Copy link
Contributor

@etpinard etpinard Sep 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ignore ⤴️ I misread the if block levels.

// The length of the value arrays should be equal and any unspecified
// values should be explicitly undefined for them to get properly culled
// as updates and not accidentally reset to the default value. This fills
// out sparse arrays with the required number of undefined values:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice touch 👌

@etpinard
Copy link
Contributor

Very lovely PR ❤️ with strong tests ⚒️

I made a few comments; I'll make a second review after reading your answers.

As an aside, legend/draw.js now probably has more click & edit logic than actual drawing logic. Do you think factoring out click & edit logic into a separate module (i.e. a few methods that take in clicked data and return restyle/relayout update objects) would make the legend code easier to maintain?

@rreusser
Copy link
Contributor Author

Okay, I've made these changes. And since most of the other code was related to drawing, I've moved the click handler to a separate file. I left text editing in place since it's moderately short, though it could also be moved.

// ways to do this (e.g. why not just `curState = fullTrace.visible`??? The
// answer is: because it breaks other things like groupby trace names in
// subtle ways.)
if(curState === undefined) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the comment 📚

@etpinard
Copy link
Contributor

💃 thanks very much @rreusser 🎉

@rreusser rreusser merged commit d78b965 into master Sep 20, 2017
@rreusser rreusser deleted the legend-visibility-toggle-rewrite branch September 20, 2017 19:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug something broken
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants