Repository navigation
undefined being thrown while redrawing with plotly_selecting #2643
Description
Crossfiltering works great with plotly_selecting except that I had to add some catch(function(){}) to suppress errors I was seeing. https://github.com/plotly/plotly.js-crossfilter.js/commit/c48b5beaf1eafbb4c5f68a1923084607c61591c5
Would be great to not have to catch-and-drop undefined.
here's the error I was seeing, sorry for the minification:
Uncaught (in promise) undefined
Promise.then (async)
r.redraw @ plotly-latest.min.js:7
t @ plotly-latest.min.js:7
redraw @ script.js:68
hist_im_select @ script.js:120
n.emit @ plotly-latest.min.js:7
t.emit @ plotly-latest.min.js:7
(anonymous) @ plotly-latest.min.js:7
l @ plotly-latest.min.js:7
r.throttle @ plotly-latest.min.js:7
i.moveFn @ plotly-latest.min.js:7
M @ plotly-latest.min.js:7
Activity
alexcjohnson commentedon May 17, 2018
I suspect it's this:
plotly.js/src/plot_api/plot_api.js
Lines 139 to 145 in fb75158
Are you adding/deleting traces to the same plot that the selection is happening on? I guess we're rejecting here because the plot hasn't actually redrawn yet, so if you expected to be able to do something like look at
gd.dataor the DOM, it would not be in the correct state. We should at least add a message to the rejection stating the reason. Alternatively, since we're not rejecting due to an error but just due to the plot not being done yet, we could imagine returning a promise that only resolves when the plot is done... wouldn't affect your usage but I worry that this could potentially deadlock existing apps. Dunno quite how it would work but some combination of event bindings that mean two plots are simultaneously waiting for each other to finish?nicolaskruchten commentedon May 18, 2018
Yes, I'm adding/removing to the same chart that's being dragged on, so as to colour them. Maybe I should restyle?
I should add that the error message is kinda gross, throwing
undefined... Is this normal onPromise.reject()?alexcjohnson commentedon May 18, 2018
Your restyle would need to change an array attribute, so it doesn't make any difference, it would go through the
Plotly.plotpathway and get rejected here as well. Best would be to see if you could avoid this altogether, and get the updates on the same chart to be handled just byselected.marker.colorandunselected.marker.color.Hence my comment "We should at least add a message to the rejection stating the reason"
nicolaskruchten commentedon May 18, 2018
I see. +1 to rejecting with a string if possible! I should note that this does work, it just also throws while it's working so maybe I could have the thing wait to redraw until it's done redrawing?
Re
selected.marker.colorI don't think that will work because the colour I want is dependent not only on the selection-state in the given chart but all the others...alexcjohnson commentedon May 18, 2018
The problem is not that it's in the middle of redrawing, it's that it's in the middle of dragging, and we defer redraws until you're done dragging. This is for like streaming data, we stop redrawing the stream while you drag (to select, zoom, pan, whatever). Maybe we shouldn't do that, we should allow redraws mid-drag, but that's a substantially bigger development effort.
Couldn't you have one trace that's "selected elsewhere" and another trace that's "deselected elsewhere", and then use
[de]selected.marker.colorto automatically bifurcate both of those traces on [de]selected here?nicolaskruchten commentedon May 18, 2018
Ah I see!
etpinard commentedon Dec 3, 2018
Merged into #3305