Plot is getting stuck in the same zoom level regardless of changes

[mbkupfer]

I can't for the life of me figure out why my plot's revision is not changing. At first, my intention was to reset the zoom when all selections from a dropdown were removed, but now it doesn't even reset at any point. I deployed an initial proof of concept a week back and had no issue, but now it seems to get stuck at a zoom level regardless of what I do with revision, uirevision, immutability-helpers, etc. I'm very new to the react world (not to plotly though), so this might be something I'm doing wrong -- likely not a bug, but I would be eternally grateful on any guidance on how to fix this.

I have created a minimal reproducible example in codesandbox that is as close to the current state of my actual viz component here: https://codesandbox.io/embed/yqn7j0v90v

As demonstrated in the gif below, the axis zoom never changes when I choose new selections. While it isn't intended to change for each selection, I do want it to reset when the dropdown is cleared, but I can't get it to reset in any case:

The gif below is taken from my initial foray into react-plotly and as you can see, the zoom resets on any selection change, but I can't figure out why this isn't the case in the sandbox code I shared:

Thanks for the help!

[nicolaskruchten]

Have you tried setting the xaxis range explicity? Zooming is implemented internally by changing the range, so resetting the range should reset the view.

[mbkupfer]

Yes that approach did work, along with many other things that I toggled around so I'm not too sure what exactly it was.

This was also related to #141, which has been fixed as well. Similar to the above, I tried a lot of different things so it's hard to say for certain what fixed it. One thing for certain though is that using uirevision helped keep the zoom state when I wanted it to stay the same, but switching back when I cleared the dropdown. I knew this was the case coming from dash background, but I think what this really came down to was a special use case along with some newbie user error since I wasn't fully understanding how to work with nested state in react which can feel very cumbersome to do, but I think I'm getting the hang of it now.

[nicolaskruchten]

Great!

I keep meaning to make a solid readme example of how to use uirevision because it's such a good solution to this problem (originally designed for Dash but applicable here of course) but I just never have the time.

[mbkupfer]

@nicolaskruchten after some reflection, I realize that my biggest hurdle was remembering the fundamental mutability that exists at all levels of the figure object. There is a lot of nuance involved when modifying properties of a plot that is not a dumb component. If one is not careful, they can easily change the value of other objects without even realizing it.

Just take the moderately tame example of changing the xaxis range. This can potentially be an array nested in 3 other objects! This is a mutable nightmare and the scale of cracks that a bug can creep in is simply unreal.

// Schema for xaxis.range
figure: {
    layout:{
        xaxis:{
            range:[]
        }
    }
}

I think for anyone trying to create dashboards with react-plotly, they should definitely first have a look at Dash. If this is not a viable option for one reason or another, then just make it crucial that they have a consistent, bug free approach to wrangling with a figure's state.

I see that the you have been meaning to update the documentation. I was thinking while that works its way down the pipeline, that maybe I could write about an approach I came up with in a repo wiki? FWIW, I'll still add my initial thoughts below and you can decide what to do.

State management with plotly schema, and why I prefer to use ramda's R.clone

Initially, I was using immutability-helper since this seemed to be what react endorsed. After working with it for a brief period I realized that this isn't the right tool for the job. Rather, what I believe is the best approach is to use ramda's clone. For instance, here is how I could update the locationmode of a choropleth figure in response to a UI toggle in the tool:

handleChangeLocationMode(selection) {
        const newData = R.clone(this.state.data)
        newData[0].locationmode = 'country names'
        this.setState({data: newData})
    }

It's concise, we are directly targeting a property, and there is no question in my mind that this is changing anything else in my state.

Now, how would this look with immutability-helper?

handleChangeLocationMode(selection) {
        this.setState(prevState => {
            return update(prevState, {
                data: { 0: {locationmode: {$set: 'country names' }} },
            })
        })
    }

There are two things I don't like about this second approach. First issue is the awkward syntax. It is a whole new domain specific language so it not only requires learning, but also adjusting to. The R.clone approach has a much cleaner aesthetic, in my opinion. The second issue, which I find even more important, is that there is no warning if you are accidentally updating a nested property which happens to be a mutable reference. In R.clone, you are making a deep copy so that thought doesn't even need to cross your mind.

Of course, there is the caveat of this not being as performant. It is basic knowledge that a deep copy will is wastes more resources than shallow ones, but in many cases, performance might just not be that big of an issue, especially compared to having comfort in knowing your code wont have an hidden bugs.