Description
If you update a figure in place - and doing so changes the axis type we would infer - we don't update the type. In this example (distilled from https://codepen.io/bpostlethwaite/pen/rpYOaX) the x axis does not update to type: 'category'
and no data is shown at the end.
var scatterTrace = {
x: [1, 2, 3],
y: [10, 20, 10]
};
var figure = {
data: [scatterTrace]
};
Plotly.newPlot('myDiv', figure);
figure.data[0].x = ['a', 'b', 'c'];
Plotly.newPlot('myDiv', figure);
Using the currently-preferred modification technique of Plotly.restyle('mydiv', {x: [['a', 'b', 'c']]})
instead, this works as expected. And the upcoming Plotly.react
is expected to handle this situation correctly as well, since it will diff and see that x
changed. But there are a few problems:
- In-place modification and replotting (either via
newPlot
orPlotly.redraw
, ala a version of .newPlot that does the .update logic behind the scenes #1850 (comment)) has long been an accepted use of our API, not one that we recommend, but more for performance reasons than because it's not expected to work. Therefore, we should make it work. - Moreover, react-plotly.js) currently works this way, until
Plotly.react
is able to supersede it. - But what if you want a non-auto axis type? You have numbers or dates but want them interpreted as categories, for example. That will get wiped out by providing new data to
Plotly.restyle
orPlotly.react
.
The cleanest (only?) way I can think of to handle this - which anyway would be more consistent with other things we do - would be to invent a new axis.autotype
attribute. This would behave just like axis.autorange
: it would default to true
, and get explicitly set to true
, unless you provide an explicit axis.type
either initially or via relayout
in which case it gets set to false
. Then during Plotly.newPlot
, Plotly.redraw
, and Plotly.relayout
for attributes with editType
including 'clearAxisTypes'
, we delete any axis.type
with autotype: true
causing the autotype algorithm to be reinvoked.