-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Immutable mode #2389
Comments
I'm a big fan of this idea and approach, as it seems to really close the gap between React's view of the world and the way plotly.js works :) |
I think for true immutability, it would also be necessary to move away from requiring the external state contain a whole DOM element ( For example, you can't serialise or unserialise a DOM element (for saving/loading to a server/local storage), and you can't shallow compare it when rendering. As a newcomer to Plotly, I've found it quite confusing how to actually handle |
@vdh I don't think it's necessary to store a whole DOM node in state. Some of our examples do this for convenience because the DOM node has |
(I'd be happy to help sort things out with some examples etc if you create an issue in https://github.com/plotly/react-plotly.js or https://github.com/plotly/react-plotly.js-editor as appropriate with your specific concerns!) |
Is there a PR for this yet or is this being developed internally? |
I just ran into this. At least while using It's probably especially an issue in React land where immutability is the default (and all of hooks is build on the idea of immutability and referential equality is structural equality) |
Came across this in the README. Is it still an issue, or being developed? |
any updates on this issue ? |
Along with
Plotly.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 except
Plotly.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 we might be able to avoid doing, but probably not until v2.So there are two things we should do:
gd.data
andgd.layout
immutably, conditional on a config argument.gd.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.See plotly/react-plotly.js#43
The text was updated successfully, but these errors were encountered: