"Joint" searching queries across multiple feature ranking/metadata fields

[fedarko]

A continuation of the ideas laid out in #132.

This would basically let the user do multiple queries of arbitrary types on the same half of a log ratio. Think sort of akin to SQL queries.

Something like "has taxonomic rank Clostridium and has confidence > 0.95".

The fact that we can already search by multiple ranks at once in taxonomy searching kinda mitigates the urgency of this but it'd still be cool to have.

i think a graphical interface for this (where the user could e.g. press a "+" button that adds another searching row) would be cool, but probs hard or tedious to pull off (esp. in vanilla-ish JS, which we're using now). An easier (and maybe more intuitive?) solution would be defining a sort of syntax for these queries, but that would take some getting used to for users (and I don't want to alienate people with that).

Some steps

• [ ] Name the numerator/denominator filtering elements' IDs such that the first are named e.g. topSearch1, topSearchType1, etc. -- there should be a numerical suffix (let's go with 1-indexing)
• [ ] Add "+" buttons to the numerator/denominator filtering stuff.
• [ ] Set up two attributes of RRVDisplay, topFilterCount and botFilterCount, both of which should be initialized to 1.
• [ ] On pressing the "+" button, all of the filtering elements for that side of the log-ratio should get duplicated, with their IDs being changed to end with (top|bot)FilterCount + 1.
  • It will be more convenient for users to duplicate the state from the previous element, so e.g. if you were searching through the Taxon field that should get copied over. (It will likely be best to mess around with the CSS so that the numerator and denominator filtering divs are separately vertically scrollable.)
  • The new elements should get inserted "in between" the old filtering elements and the "+" button, if that makes sense.
  • Furthermore, the new elements should be preceded by a dropdown menu (let's call it topConjunction1_2 or something) with options like "AND", "OR", and "AND NOT". These would define how filtering results are chained together, and would let us do fancy stuff like "in the bottom 10% of rankings AND NOT contains [this text]", etc.

This might negate the need for stuff like #308, if we can get to this in time.

The main hurdle here will probably be making the JS do this stuff in a way that is sustainable and easy to test. If we can get to this it'd be super useful.

[fedarko]

I'm upgrading this to "important", because this is coming up a lot and I think having it supported would be really useful. In particular, use cases like "the bottom-ranked X% of features, excluding the text T" will be super helpful for analyses on datasets where the numerator taxa being inspected aren't all highly ranked (and we want to take a denominator from the bottom few features without also selecting the taxa here that are in the numerator).