waffle tips

[Fil]

Positions the tips on waffle marks by “hacking” the x1, x2, y1 and y2 channels, replacing them with the centroid of each waffle, in pixel space.

This kind of works, but it's not satisfying at the moment, because the mark has too little control on where the tips should appear. Currently it can only set px, py to say where the tip should be triggered, but the tip's position can only be controlled by "data" channels (x, y, x1, x2, y1, y2), read by the derive function.

TODO:

• make it less hacky (possibly by allowing px, py to also drive to position of the tip, not just of the pointer?, or by making derive aware of the scaled values (which we could then hack similarly, instead of hacking the source channels)
• make the shape (and centroid) computation happen in the initializer instead of render? would feel cleaner, and would allow to make a tip mark with the same geometry but without actually calling the waffle mark.
• more tests (waffleX, facets…)
• restore the y channel in the tip contents.
• [ ] allow tip: {maxRadius: Infinity} (would be welcome in the waffleTip test) (tracked as Erroneous type definition for the tip {maxRadius} option #2134 since it's not linked to this mark)

closes #2129

[mbostock]

A quick note because I’m not sure I have the bandwidth to work on this now, but I think this should work more like the implicit centroid transform for the geo mark. For one thing, we don’t want the waffle mark to do anything if the tip option isn’t being used. And for two, it might be possible to move this transform/initializer onto the derived tip mark by transforming the tip option (that gets passed through as options to the tip mark), rather than doing the transform on the waffle mark itself.

[Fil]

Would it be interesting to have a way for an initializer to suppress an existing channel (e.g. by returning channels: {y1: null}) ? In this case we could censor y1 and y2, and return y alone, removing the need for the new hint.

(tracked as #2136)

[Fil]

Another way of having the right tooltips without the hint would be to change the pair formatting of (a, b) to display a when format(a) === format(b). I think it's a good idea in its own right, too? If the format does not discriminate between the two values of an interval, it seems better to display, say "3" than "3—3".

(tracked as #2135)

[Fil]

we don’t want the waffle mark to do anything if the tip option isn’t being used

I now disagree with this, because I want to highlight the particular waffle that is being moused over, and that requires the same secondary initializer to derive centroids, otherwise the highlighted waffle is decided by the corresponding bar position.

export function wafflePointer() {
  const random = d3.randomLcg(42);
  const data = Array.from({length: 100}, (_, i) => ({x: i % 3, fill: random()}));
  return Plot.plot({
    y: {inset: 12},
    marks: [
      Plot.waffleY(data, {x: "x", y: 1, fill: "#888"}),
      Plot.waffleY(data, Plot.pointer({x: "x", y: 1, fill: "fill"}))
    ]
  });
}

EDIT: I tried unsuccessfully to see if we could use the same actual centroid transform.

[Fil]

I've fixed the waffle centroids. The number of cases when you include the logic for fractional values is… insane.