Plotly.deleteTraces leads to bad trace uid sequence

[etpinard]

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

	for(i = 0; i < sceneData.length; ++i) {
	data = sceneData[i];
	if(data.visible !== true) {
	continue;
	}
	trace = this.traces[data.uid];
	if(trace) {
	if(trace.data.type === data.type) {
	trace.update(data);
	} else {
	trace.dispose();
	trace = data._module.plot(this, data);
	this.traces[data.uid] = trace;
	}
	} else {
	trace = data._module.plot(this, data);
	this.traces[data.uid] = trace;
	}
	trace.name = data.name;
	}

cc @alexcjohnson

[alexcjohnson]

Ah interesting... good catch, because of how getTraceUids pulls uids out of oldFullData, 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 in fullData? Are there similar bugs due to relinkPrivateKeys after a delete etc?

[etpinard]

I guess the easiest may be to mirror these operations in fullData

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]

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