Should it be possible to filter the _tip_ mark when creating it implicitly via the _tip_ option on a different mark?

[mwaibel-go]

Consider this plot definition:

Plot.dot([[1, 1]], {tip: {filter: () => false}}).plot()

The tip object above is passed to to the Tip mark constructor, which has no documented filter option. So we cannot actually disable tips based on the displayed data (or generally). I’m wondering if we should.

My actual use case involves the need to access the (transformed and binned) data for a mark on hover. I’m trying to avoid duplicating these computations when using the Pointer mark. I was working off of the Histogram selection example, but I don’t need the tip mark.

The same behaviour can be achieved by overriding the render function:

Plot.dot([[1, 1]], {tip: {render: () => null}}).plot()

[mbostock]

It doesn’t work because the tip mark that is derived when you use the tip option copies over the mark state from the originating mark (the dot), ignoring the filter transform:

plot/src/plot.js

Lines 516 to 520 in 1c6b239

	function derive(mark, options = {}) {
	return initializer({...options, x: null, y: null}, (data, facets, channels, scales, dimensions, context) => {
	return context.getMarkState(mark);
	});
	}

The goal of sharing state rather than recomputing values is mainly performance, but it also helps if for some reason any of the channels are nondeterministic (which is rare… but maybe you want to jitter some points).

Maybe you could explain a little more about what you want to do with the (transformed and binned) data on hover? A render transform might be the right choice. You could also use the pointer transform on another mark, and repeat your transforms (duplicating the computations), rather than using the tip option.