You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 or Plotly.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 or Plotly.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.
Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson
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.Using the currently-preferred modification technique of
Plotly.restyle('mydiv', {x: [['a', 'b', 'c']]})
instead, this works as expected. And the upcomingPlotly.react
is expected to handle this situation correctly as well, since it will diff and see thatx
changed. But there are a few problems: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.Plotly.react
is able to supersede it.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 likeaxis.autorange
: it would default totrue
, and get explicitly set totrue
, unless you provide an explicitaxis.type
either initially or viarelayout
in which case it gets set tofalse
. Then duringPlotly.newPlot
,Plotly.redraw
, andPlotly.relayout
for attributes witheditType
including'clearAxisTypes'
, we delete anyaxis.type
withautotype: true
causing the autotype algorithm to be reinvoked.cc @etpinard @bpostlethwaite
The text was updated successfully, but these errors were encountered: