Re-set autobin when defaults override.

[mdtusz]

Fairly straightforward fix. Take a look and let me know if there's a more suitable place to put this logic.

[etpinard]

this belongs in Plotly.restyle

[etpinard]

hmm, on second thought, moving this block to restyle would not fix the problem in Plotly.extendTraces

[etpinard]

@mdtusz (cc @alexcjohnson @cldougl)

Times where the calc or plot step adds attributes to user data:

• histogram and histogram2d calc step: xbins and ybins when autobin? is true
• contour calc step: contours when autocontours is true
• contour plot step: zmin and zmax when zauto is true and coloring set to 'heatmap'
• heatmap calc step: zsmooth when data can't be smooth using the 'fast' algorithm.
• colorscale calc: zmin / zmax or cmin / cmax + colorscale when zauto or cauto is true

[etpinard]

Updating histogram data should clear the computed xbins and ybins, but the other cases aren't as obvious.

Should updating contour data clear the computed contours attributes? I'd vote for no.

Should the updating data linked to a colorscale update the bounds of the colorscale? I'd vote for no also.

So, looks like xbins ans ybins are in a league of their own.

[mdtusz]

Is it possible for a restyle/extendTraces to display incorrectly on plots using contours or colorscales? E.g. extending a trace to a point where the initially generated contous will be incorrect?

[etpinard]

@mdtusz

display incorrectly on plots using contours or colorscales?

everything is displayed correctly. My comment referred to the computed auto contour and auto colorscale ranges.

For example, at the moment, starting from a heatmap trace with zauto true (which is the default btw), calling Plotly.restyle with new z data doesn't re-compute zmin and zmax.

I think this correct. Updating heatmap data should not magically re-compute the colorscale range.

[etpinard]

@mdtusz this turns out to a pretty hard problem.

First, the problem of #24 only affects restyle/extendTraces calls with new data outside the computed [ xbins.start , xbins.end ] interval (or the corresponding ybins interval for horizontal histograms).

e.g.

Plotly.plot(Tabs.fresh(), [
    {
        type: 'histogram',
        x: [ 0, 1, 1, 2, 2, 2, 3, 3, 4]
    }]
).then(function(gd) {
    Plotly.extendTraces(gd, {x: [[2,2,2,2]]}, [0]);
}).then(function(gd) {
    Plotly.restyle(gd, {x: [[0,0,0,1,2,3,3,3,4,4]]}, [0])
});

behaves as expected.

Now, consider the case where a user sets the xbins manually and then calls restyle/extendTraces:

Plotly.plot(Tabs.fresh(), [
    {
        type: 'histogram',
        x: [ 0, 1, 1, 2, 2, 2, 3, 3, 4],
        xbins: {     // N.B. this defaults fullTrace.autobinx to true
           start: 0,
           end: 4,
           size: 1
        }
    }]
).then(function(gd) {
    Plotly.extendTraces(gd, {x: [[2,2,2,2]]}, [0]);
});

then, the extendTraces call should not clear the set xbins. The patches on this branch make restyle and extendTraces clear them, erroneously.

I'm not sure what the solution should be.

We could to find a way to extend the [ xbins.start, xbins.end ] interval on restyle/extendTrace only when oldFullTrace.autobinx is true, somewhere in supplyDefaults like you have it here. To note, the histogram calc step fills in xbins but does not touch autobinx. Even then, I'm not convinced it's the way to go.

[mdtusz]

At present, this PR will likely create more issues than it solves, so it is being temporarily closed.