.animate method that can handle any type of figure diff

[chriddyp]

In Dash, I'd like users to be able to toggle on and off an animate property which would either smoothly transition points (if available) or just update the chart.

Right now, Plotly.animate doesn't work with all chart transitions and data transitions. While I could program this myself in the Graph component, it would be great if plotly.js could do this so that everyone could benefit. We could even use this in the workspace to smooth out transitions!

Ideally, I would just replace the .newPlot(id, data, layout) call with a .animate(id, data, layout) call and call it a day.

In particular, here are some of the edge cases:

• .animate to work before .plot is called
• .animate to work across all chart types (even if it's not a smooth animation)
• .animate to autorange (expand axes if the new data was larger than the existing data)
• .animate when new traces are added or removed
• .animate when chart types have been changed

I'm OK if this is a new method or a new config option or whatever.

---

cc @rreusser @alexcjohnson @etpinard @cpsievert @monfera @jackparmer

[etpinard]

.animate to autorange (expand axes if the new data was larger than the existing data)

That's arguably not always the desired behavior. We'll probably need another attribute.

Related:

• Range selectors + streaming and/or markers #387
• Implement different data-based autorange mode #928

[chriddyp]

.animate to autorange (expand axes if the new data was larger than the existing data)
That's arguably not always the desired behavior. We'll probably need another attribute.

If autosize=true, I think that I'd argue that this is the expected behaviour. If the user wants to restrict the range to a certain view, they can set the range manually.

[monfera]

I 👍 -d @etpinard's comment b/c sometimes expansion (or shrinking) is not the intent - indeed, keeping the range(s) constant is achievable by explicitly setting the range. I was thinking of a boolean stickiness attribute (true: retain the initial autodomain vs. false: expand/shrink as needed) but it may be unnecessary complication as the range can be directly set as you suggest. It's likely I didn't have the same thing in mind as @etpinard, just wanted to add my thought.

Btw. it might occur more often that data is removed, yet one wants to preserve the original full domain (eg. when eliminating points via crossfiltering), than that data is added, yet one would not want to see them.

Even with crossfiltering point elimination, setting an explicit range would work, though it's slightly more convenient to rely on plotly.js for the initial (full) range calculation than doing it in userland (or crossfiltering) code as it'd just duplicate aggregation (extent calculation) logic.

[etpinard]

If autosize=true, I think that I'd argue that this is the expected behaviour.

Right, if a user explicitly set autosize to true, I agree. But, autosize defaults to true when the axis ranges aren't valid. In that case, I suspect keeping the first view when animating is more desirable.

[alexcjohnson]

keeping the first view when animating is more desirable

Doesn't that mean the rendered plot will be out of sync with the input state? I know we push ranges back to the input state, but autorange: true is supposed to mean that it will recalculate the ranges to fit the given data, and indeed if you copy the figure json and make a new plot with it that will happen. Or if you change the data using restyle for that matter.

Perhaps we need a new autorange setting (autorange: 'once'?) that will run autorange once and then revert to false (pushed back to the input state), to account for all these desires.

[nicolaskruchten]

FWIW I would favour having an animate flag somewhere such that .react() would animate a transition or something like that, rather than a .animate() method.