Add range filter for numerical properties other than date, e.g. S1 mutations

[corneliusroemer]

Some filters act on numerical data, like S1 mutations or titers. It would be nice if it was possible to filter for a range of these values rather than just being able to pick a single one. This would be especially useful now that we can zoom to selected.

[jameshadfield]

👍 this would be especially helpful for temporal scales (e.g. "report date"), were we to have temporal scales in auspice 😉

Are you suggesting the dataset JSON defines bins, which one could select, or that we implement the ability to type a query such as "S1 mutations = (0, 10)" or that there's some other UI?

[corneliusroemer]

I would very much like this feature, a filter for continuous/numerical properties. Should we maybe give this a help wanted label? Maybe @victorlin could have a look once the date stuff is done? It should be easier than dates, becaue there's no need to do anything with sliders. Just a dropdown to select the property to filter on and two text boxes for min/max.

[jameshadfield]

I would very much like it too!

Currently filters can be enabled for continuous variables: every single value (on the tree) will be represented in the dropdown, and the ordering will be via string-sort, for instance:

For continuous & temporal [1, 2] variables, I suggest we add one entry to the dropdown. Selecting this adds an element to the sidebar similar to the date slider [3] where we can select a range to filter on.

The same UI element could be duplicated in the footer element. Filters badges in the header could be as they currently are, except that the text conveys a range rather than a value. (Aside: we need to add the category to these badges, rather than just the value.)

Internally, each filter value (e.g. an individual country) is represented by an array of objects, each {value: filterValue, active: true/false}. The simplest (and extensible) would be to represent continuous & temporal scales by {minValue: X, maxValue: Y, active: true/false}

[1] see #1427. I suggest that issue is closed before implementing this one.
[2] We have ordinal values however they are not frequently used. I would leave them out at this stage.
[3] a reusable component would be good here!