Props should not be mutated by Plot component

It seems like the Plot component mutates its props (at least layout) instead of cloning the data. Mutation of props is to me unexpected (and undesired) behavior for a react component.

If for instance the layout is stored in the state of a component and then fed to the Plot component as a prop, like

render() {
  <Plot
    layout={this.state.layout},
    ...
    />

we will have a problem, since this.state only should be updated with the react setState() method.

[swiperii]

@nicolaskruchten

You asked for how this caused a problem in our case, and while the state example I gave was a simple example of where things could go wrong when props are mutated, it perhaps did not describe a realistic scenario very well 😃

The problem we have run into was a bit more complex. But basically we have a page with a list of objects, lets call them processes. When clicking on a process, the user is routed to another page displaying a plotly graph of the process status.

The data comes from a web API through the redux store, while the layout is a template object constant, that only sometimes is modified depending on the data. Both are fed to a Wrapper component containing the plotly Plot component. Going back from the plot page to the list page, the Wrapper and Plot components are unmounted and destroyed.

Now, going to another plot, using the same layout object (which originates higher up in the component tree, and thus not destroyed) we may suddenly have extra properties like selected tool or zoom range (depending on how the user interacted with the last plot) in our newly created plot that we did not expect.

Now that we know that props are mutated, it should be possible to work around until you have a longterm solution to what I understand is a complex problem. However, in the meantime, would it be possible to add this information to the documentation, e.g. in the Plotly component API?

[jobh]

To second @gimbo’s comment, we got only blank space where the plot was supposed to be after refactoring to use redux-toolkit (which uses immer under the hood). This was part of a larger refactoring, so it took some time to figure out the problem — no errors logged, but the debugger revealed it of course.

In this case, the workaround is to disable immer’s auto freeze functionality:

import { setAutoFreeze } from 'immer';
setAutoFreeze(false);