You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
API for deleting transforms and other new Plotly.js components #1069
Yes, this is a downside of the container array format. One small caveat here is what happens if something references, for example, transform[3].values and you delete transform #2. I think it's possible to overwrite 'transform[2]': {} so that it becomes a no-op, but that's not quite ideal.
As far as writing referencing code I don't see transforms any differently from traces or annotations. Plotlyjs supports deletion in both cases.
We use UIDs in Plotly application code for exactly this reason. I imagine other application writers are accustomed to doing the same. It adds a layer of indirection (find the index that has a matching UID before making a Plotlyjs call) but it is expected when writing non-trivial applications.
One possible approach: change nestedProperty array lookup code so that if the array index is not an integer (e.g. transforms[stringId]) then it will look though the array for the object with uid: 'stringId' instead. Ideally that would not affect any existing code, but it's just a little weird. (though are uids just string integers by default?)
As far as writing referencing code I don't see transforms any differently from traces or annotations. Plotlyjs supports deletion in both cases.
Oh, wait. I'm confused then. Isn't the API the same for modifying annotations and transforms? Does relayout succeed in deleting them where restyle fails?
There are specific lines of code for dealing with annotations that have not been replicated for transforms. There isn't a general array mutation pathway in relayout or restyle.
Got it. I understand now. Thanks for clarifying. Those should be replicated; I'll just reiterate quickly my concern about having built a system that may actually include references to the array indices in other potentially-arbitrary places. (like an animation modifying transforms[0].value)
Activity
rreusser commentedon Oct 24, 2016
Yes, this is a downside of the container array format. One small caveat here is what happens if something references, for example,
transform[3].valuesand you delete transform#2. I think it's possible to overwrite'transform[2]': {}so that it becomes a no-op, but that's not quite ideal.bpostlethwaite commentedon Oct 24, 2016
As far as writing referencing code I don't see transforms any differently from traces or annotations. Plotlyjs supports deletion in both cases.
We use UIDs in Plotly application code for exactly this reason. I imagine other application writers are accustomed to doing the same. It adds a layer of indirection (find the index that has a matching UID before making a Plotlyjs call) but it is expected when writing non-trivial applications.
bpostlethwaite commentedon Oct 24, 2016
And for trivial cases like single run scripts I doubt deletion is used frequently.
rreusser commentedon Oct 24, 2016
One possible approach: change
nestedPropertyarray lookup code so that if the array index is not an integer (e.g.transforms[stringId]) then it will look though the array for the object withuid: 'stringId'instead. Ideally that would not affect any existing code, but it's just a little weird. (though areuids just string integers by default?)rreusser commentedon Oct 24, 2016
Oh, wait. I'm confused then. Isn't the API the same for modifying annotations and transforms? Does
relayoutsucceed in deleting them whererestylefails?bpostlethwaite commentedon Oct 24, 2016
There are specific lines of code for dealing with annotations that have not been replicated for transforms. There isn't a general array mutation pathway in relayout or restyle.
rreusser commentedon Oct 24, 2016
Got it. I understand now. Thanks for clarifying. Those should be replicated; I'll just reiterate quickly my concern about having built a system that may actually include references to the array indices in other potentially-arbitrary places. (like an animation modifying
transforms[0].value)