Plotly.react axis reset method not working as expected in dash context

[cldougl]

Zooming and then resetting axis in this example: https://codepen.io/plotly/pen/VdPbMa?editors=1010 will autoscale to autorange rather than respecting the manually set ranges as in this working example: https://codepen.io/plotly/pen/YXbwyo

[alexcjohnson]

I guess the question is really what you mean by "resetting" the axis - to what initial state? In your bug codepen you first make the plot with no layout, ie autoranged, so that becomes the state to reset to. How can we tell that you meant the second state, after the Plotly.react call, to be the reset state and not just a temporary mutation?

Put another way, how can we tell the difference between the change you made with Plotly.react, which you expected would clear the reset ranges, and any other change, including user-initiated zoom and pan (where it would be rather silly to clear the reset ranges...)

Anyway your point is well taken, there certainly are cases where you want these ranges to reset - if you make a totally different plot in the same div, for example, the reset ranges could bear zero resemblance to the new data. I'm just not sure how to distinguish these cases. I suppose we could make initial range into a regular attribute that, if omitted, we write back into gd.layout during the first draw; then any Plotly.react call that's not basing its layout on the previous state will automatically reset it. We've been trying to get away from mutating the figure during drawing though.

@etpinard thoughts?

[etpinard]

I think the behavior in https://codepen.io/plotly/pen/VdPbMa?editors=1010 is correct (albeit maybe not optimal for the dash renderers). If users want to reset the "initial" axis ranges, they can always call newPlot as in https://codepen.io/etpinard/pen/mKWLyz?editors=0010. But yeah, I understand this may not be possible for Dash users.

The idea of adding a rangeinitial attribute (and perhaps a camerainitial in 3D) is interesting, it would make it easy for users to clear these "initial" ranges (e.g. Plotly.relayout(gd, 'xaxis.rangeinitial', null) would suffice). That said, to work properly we would probably need to mutate gd.layout.

[chriddyp]

If users want to reset the "initial" axis ranges, they can always call newPlot as in https://codepen.io/etpinard/pen/mKWLyz?editors=0010.

OK, it seems like there is some preserved state in Plotly.react that I wasn't aware of. Are there any other cases where subsequent updates with react will be different than with newPlot? I have been assuming that the behaviour for Plotly.react was identical as Plotly.newPlot and 'creating a new graph' is how most dash users expect graph updates to work.

Now, I would switch back to newPlot but there was the issue of the webgl contexts (#2423).

I'm OK with modifying this behaviour in Dash's Graph component, I think I just need to understand better how react differs from newPlot

[etpinard]

Are there any other cases where subsequent updates with react will be different than with newPlot?

Other than bugs, I can't think of anything.

I'm OK with modifying this behaviour in Dash's Graph component

Clearing cartesian ax._rangeInitial, 3d scene._scene.cameraInitial and geo/polar/mapbox viewInitial before calling Plotly.react in Dash should suffice. We can provide a method (e.g. named Plotly.Plots.clearInitialViews) to make this task easier.

Alternatively, we could clear all these _ fields in Plotly.react itself. This could be considered a breaking change though. It would make Plotly.react a little more like Plotly.newPlot and a little less like Plotly.update. I'm not sure if that's better or not.

[szechyjs]

I have a similar issue where I am changing the data being plotted using Plotly.react this works as expected and autoscales to the data. However, if the user has made any changes to the plot zoom/scale/axes the plot does not autoscale after calling Plotly.react with the new data.

[zouhairm]

Another use case where this is a problem: In a Dash application I have a mapbox where the lat/lon ranges depend on a dropdown (i.e. different regions of world are displayed). User can map/zoom to see the data being graphed, but if they dbl-click, the axis is reset to the original range.

I thought uirevision would help take care of that, but that doesn't seem to be the case?
Any updates on a potential fix to this?

[edgdul]

We found a related issue with Plotly.react

1. Create a plot using Plotly.newPlot. It contains multiple yaxes with fixed manually specified ranges. e.g. range : [-0.3, 1] , and has actual values lower that the upper range (e.g y=0 and y= 0.25)
2. Later we need to add another yaxis at the bottom, so call Plotly.react and pass newly constructed arrays of data and layout
3. Afterwards, if "Reset Axes" action is performed, the hardcoded ranges are overwritten with the values calculated by Plotly from actual data on those axes
   This is incorrect, because axes should remain with the given hardcoded ranges.
   Explicitly specifying autorange : false doesn't help either

Problem disappears if we switch back to using the slower Plotly.newPlot to do a major update for the data+layout.

[Tunneller]

Any update on this? I would like that when users click the Home icon that Reset Axes takes that back to an initial layout. Can I trap clicking on the Home button (and insert some of my own code? e.g. I could have previously saved the original layout somewhere and have Home button call newplot? Or there is something alluded to above that clearing ax._rangeInitial is all that is needed?)

Thanks,

[Tunneller]

Ahh. I see how to do this last point. I can delete the existing modeBarButton for "Home" but add another button that uses the same icon, and now I have complete control over what happens when user clicks this. Cool.

[gvwilson]

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