a details channel

[Fil]

A details channel is created on all marks. By default it is populated with the existing channels (x, y, fill, text…), but it's possible to define it with Plot.identity instead.

When the details on a mark are non-null, we store them details and the scaled geometry (x, y) as local variables.

A mark (such as Tooltip) can retrieve those across all marks, and use the geometries to infer the closest mark and display the details.

This generic approach might allow to:

• have details by default (extracted from the variable channels)
• set details to be the data (Plot.identity) or anything else
  • perf. issue: special-case when it's the data to avoid creating a derived object?
• have tooltips by default on all marks
• remove default tooltips from marks which don't need them (axes, etc.)
• remove all tooltips by setting a top-level tooltip: false option (could also be opt-in)
• the tooltips (or other interaction mechanism) could be a mark, like axes, that could be set to a different mode than the default

This PR is just a way to organize some of the questions:

• where and how do we store the details
• where and how do we store the geometries (or position information)
• how would transform handle these
  • in particular, do we also need to pass the "original point index" when a transform groups values? so that brushing on a bin or group could change the selected value of the original points.

Just to give a hint of what could be done, the penguinCulmen test has a custom tooltip mark which just puts some html in a foreignObject. But this should be designed in a separate PR.

[mbostock]

I’m currently working on a tooltip mark that has its own channels (and functions independently of other marks, similar to other prototypes we’ve built). It’s interesting to see your take on a tooltip that is driven from existing marks rather than having its own channel definitions, and I appreciate you sharing this exploration. At least for now I think we’ll still want the more “traditional” approach of independent channels, but I especially like that this hints at how we might make tooltips more automatic in the future.

Two observations on this approach.

Materializing an object for every element in the data, especially for information that we already have and for something that is not going to be used by default, is wasteful. I feel a better approach would be to read from the existing channel arrays. And if we do need to make copies, we should use a columnar representation (object-of-arrays instead of array-of-objects) to avoid creating many objects. We could also consider how to make this lazy.

I also think it’s important to think of the details channel as a public signal that users control rather than an artifact of how the tooltip is implemented, i.e., we want to make it easy for users to provide information that is not already present in the channels, and to control which (already available) channels are desired to appear in tooltips. Having to specify the entire key-value object is more cumbersome than being able to reference existing columns, and I don’t think we should offer the capability to “show the entire data” (because this ties us into the array-of-objects representation and does not include an explicit schema, so our ability to show missing fields and infer types is harder etc.).

[mbostock]

Superseded by #1527? Shall we close?

[Fil]

yes!