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

fix #2452 - removing and adding scatter(gl) as not the first module #2455

Merged
merged 2 commits into from
Mar 8, 2018

Conversation

alexcjohnson
Copy link
Collaborator

We have special logic for when scatter and scattergl modules are removed from the plot, and it was broken.

cc @etpinard

if(oldModules[i].name === 'scatter') {
hadScatter = true;
}
break;
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The main problem was this break being outside the if. But then since we had the same loop twice and it's unlikely in general for both scatter and scattergl to be present, I combined them into one and dropped the break altogether.

@@ -610,7 +610,9 @@ function sceneUpdate(gd, subplot) {
scene.selectBatch = null;
scene.unselectBatch = null;

delete subplot._scene;
// we can't just delete _scene, because `destroy` is called in the
// middle of supplyDefaults, before relinkPrivateKeys which will put it back.
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

⚠️ ⚠️ This could apply to anything during cleanPlot ⚠️ ⚠️

If you ever run into a situation like this "but I deleted that, how come it's still here???" try setting it to null instead.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

So after fixing the break issue so traces could get removed, scattergl had a new bug that it wouldn't come back after being deleted - because the scene had been destroyed but we were trying to draw traces into it again. Hence my tests below that remove and then re-add the traces. There were related issues, like if you hid the last scattergl trace and then tried to add a totally new one it wouldn't show up either, but it's all the same issue so I just tested original case.

Copy link
Contributor

Choose a reason for hiding this comment

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

Nice. I vaguely remember reading that delete was slow. Perhaps setting subplot._scene = null will be a perf boost too 🐎

@alexcjohnson
Copy link
Collaborator Author

This also fixes #2309 🎉

@etpinard etpinard added bug something broken status: reviewable labels Mar 8, 2018
}
moduleName = newModules[i].name;
if(moduleName === 'scatter') hasScatter = true;
else if(moduleName === 'scattergl') hasGl = true;
Copy link
Contributor

Choose a reason for hiding this comment

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

Great. We should starting thinking about generalizing this pattern.

In short, this loop and its has?? flags exist because scatter and scattergl do not clear their content on redraws unlike other trace types. A goal of ours should be to update all cartesian trace module plot steps to something more d3-iomatic for (1) work with animations (2) what could be nice performance gain on redraws.

@etpinard
Copy link
Contributor

etpinard commented Mar 8, 2018

Nicely done 💃 🎉

@alexcjohnson alexcjohnson merged commit 3c5d238 into master Mar 8, 2018
@alexcjohnson alexcjohnson deleted the legendonly-fix branch March 8, 2018 03:48
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