Along withPlotly.react, it would be nice if we would never mutategd.data andgd.layout, just make new changed objects and alert the user to the change. We can't make this the default behavior in v1 since some users depend ongd.data andgd.layout keeping the identity of the objects they initially passed in - though there are some cases already where they are not. But that rule holds well enough that some folks depend on it, so immutability would have to be aconfig argument.

In general all of the plot modification methods exceptPlotly.react (Plotly.restyle,relayout,update,extendTraces etc..) modifygd.data andgd.layout in place to make the requested updates. Most (but not all) then emit an event you can use to see that the plot state has changed. But also there are modifications that happen automatically during drawing the plot, principally (if not entirely) pushing auto values (axis ranges, colorscale ranges) back togd.data andgd.layout so that future minor updates don't need to recalculate these. This too is something wemight be able to avoid doing, but probably not until v2.

So there are two things we should do:

• Make all updates togd.data andgd.layout immutably, conditional on a config argument.
• Streamline the way we alert the user that the state has changed, so that they can feed this new state back into their app state. It seems like once we have immutable changes, itmight be possible without any changes to the events from plotly.js... the react wrapper would have to bind to all the events that might carry state changes initiated from the UI, and also check after every update initiated by the wrapper itself, whethergd.data === prevData andgd.layout === prevLayout... but seems like it would be much easier for the react wrapper if there were a single "new state" event that collects all of these.

Seeplotly/react-plotly.js#43