enable persistence of selection info to the layout

[alexcjohnson]

Part of #1851 - split out so we can discuss it separately

To make it possible to retain selections across redraws or create a new selection programmatically, the selection data should be part of the layout. This also means that when you finish a selection, in addition to the plotly_selected event you'll also get a plotly_relayout event. Probably no changes in the middle though (ie with plotly_selecting).

So what should these attributes look like? We need to describe the selection in data coordinates, including which axes / subplot we're selecting on; we need to support rectangular and lasso selections, as well as shift-select combinations of multiple regions and simultaneous selections on different subplots.

So I propose:

layout.selections = [{
    subplot: 'xy',
    type: 'rect',
    x: [5, 10],
    y: [-3, 6]
}, {
    subplot: 'x2y2',
    type: 'lasso',
    x: [5, 6, 5, 4, 2, 3],
    y: [9, 8, 7, 7, 8, 9]
}, {
    subplot: 'geo3',
    type: 'rect',
    geo: [[-113, 72], [-108, 22]]
}]

One tricky case here around geo subplots: for many projections when you pan or zoom, what was a rectangle is no longer a rectangle, what was a straight line is no longer straight. We may need to either (a) convert rect to lasso, and increase the density of points on the lassos when you pan/zoom after making the selection, or (b) keep track of the projection parameters in effect when the selection was made, so we can transform it to an accurate representation in the new projection. Option (a) will never be perfect, and will have occasional edge cases where it breaks down spectacularly, but (b) means adding a complicated bunch of logic to the drawing and point selection routines, and may have performance implications. mapbox may have some of this issue, as it supports rotating and tilting, though straight lines are still pretty close to straight when the map is tilted even if they are no longer x/y aligned. polar too, in the case where users set a nonzero inner radius.

[nicolaskruchten]

will this stay coordinates with selectedpoints ?

[alexcjohnson]

Great question - when the user is creating or modifying the selection via GUI we'll set them both, but when rendering or rerendering the graph it seems like you might want it either way:

• If you passed in trace.selectedpoints without layout.selections you pretty clearly want selectedpoints to stay there.
• Unless you're trying to programmatically clear the selection, in which case you could detect that layout.selections is empty and wipe out trace.selectedpoints, but that could be cumbersome.
• If you pass in layout.selections and the data has changed, most likely you want selectedpoints to update to the new set of points within the selection.
• But maybe there's a case where you want to make a selection, then let the data evolve and see where those selected points go?

So perhaps we need a boolean attribute that explicitly says "when replotting, do I recalculate selectedpoints to match selections?" Like layout.syncselectedpoints or something? layout.syncselections? layout.reselect?

[nicolaskruchten]

All good questions. Maybe they all roll up into "what to do if selectedpoints and selections don't match?" The options are, basically to trigger a relayout to force selectedpoints to match selections, or not, which could be controlled by a boolean.

[archmoj]

Regarding selectedpoints, this part of the code looks pretty strange to my eyes: https://github.com/plotly/plotly.js/blob/13773569a94d80f61459fa5b4aaf2166cba3b3a5/src/plots/cartesian/select.js#L788-L835

Why both trace.selectedpoints and trace._input.selectedpoints are mutated?

[alexcjohnson]

Probably because we want the result to be as if we had called restyle providing the new selectedpoints, but we don't want the overhead of a full restyle call.

[jakeflorentine]

This causes a large issue when trying to sync selected points between multiple plots (non-sub-plots). If the selections array even had an ids option that would be great