Repository navigation
Plotly.deleteTraces leads to bad trace uid sequence #2836
Description
Consider
Plotly.newPlot('graph', [{
y: [1, 2, 1]
}, {
y: [2, 1, 2]
}, {
y: [3, 2, 3]
}])
.then(gd => {
console.log(gd._fullData.map(t => t.uid))
// => ['0', '1', '2']
return gd
})
.then(gd => {
return Plotly.deleteTraces(gd, [0])
})
.then(gd => {
console.log(gd._fullData.map(t => t.uid))
// (currently) => ['0', '1']
// (in 1.38.x) => ['1', '2']
})In a codepen: https://codepen.io/etpinard/pen/KBmVYB?editors=1010
This is probably due to #2681 and probably leads to bugs (not yet reported) when deleting traces in subplots that track traces using uids e.g. gl3d:
plotly.js/src/plots/gl3d/scene.js
Lines 452 to 471 in 180b6b9
Activity
alexcjohnson commentedon Jul 23, 2018
Ah interesting... good catch, because of how
getTraceUidspulls uids out ofoldFullData, any operation that can alter existing trace indices - so not just delete but also move and add (if not adding at the end) - will have the same issue. I guess the easiest may be to mirror these operations infullData? Are there similar bugs due torelinkPrivateKeysafter a delete etc?etpinard commentedon Jul 24, 2018
This won't be trivial for graphs with one-to-many trace transforms (e.g. groupby), what if instead we mirror these operations on a uid stash?
gvwilson commentedon Jun 11, 2024
Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson