feat: add activateOn to interval1D and interval2D to define when a selection should be activated

[domoritz]

I found that for very large datasets where index creation takes a few seconds, it can be better to only activate a selection on click instead of hover.

[jheer]

I like this! However, we might want to wait on merging for now. I also want to think through some complementary possible changes, such as adding a query queue in the Coordinator (not just within a DB client) to enable more fine-grained control of execution / ordering / canceling. Ultimately such changes may prove orthogonal to this one, but I want to approach it holistically.

[domoritz]

I like the idea of a more holistic approach. It would be great to also support activating a chart when the user hovers for some time rather than just on a simple mousenter or mousedown event.

I will need this change for a local experiment but we don't need to merge it yet.

[jheer]

Ooh, having a reusable set of activation methods (shared across various interactors) sounds like a promising direction. Would be worth enumerating what we think that space of methods should be.

[domoritz]

I'll start

• mousedown
• mouseenter
• mouse stays for X ms
• touchstart
• mouse moves towards the chart (using https://github.com/mathisonian/premonish, which Matt actually implemented for Falcon)

[jheer]

To which I would simply add:

• Prefetch on load (i.e. precompute all indexes for individual active views/clauses)

Right now individual interactors make their own activation decisions. This conversation is making me also think of more coordinated strategies. Right now Selections include resolution strategies (which I plan to abstract to make "pluggable" in the future). Selections may also be the right place to include activation strategies, which might be shared across multiple interactors.

[domoritz]

This reminds me of another feature. I'd like to restrict the number of brushes. It would be nice to have only one brush or two brushes as then we could make good guarantees about the performance or precompute indexes (a la immens).

[jheer]

Single brush support is already provided at the Selection level via the single resolution strategy. What remains is to standardize some kind of reset() method on a (to-be-formalized) "Interactor"/"SelectionSource" interface. That way a Selection can inform sources to remove visual brushes, etc., when a source's selection clause is removed. The corresponding implementation details should be easy once we decide on the interfaces/architecture.