V2 filtering_settings

a placeholder issue to discuss the next version of the filtering_settings property. In particular:

• Its name
• Its structure: is it a string that the user has to parse or a more complex object?
• What does the grammar look like? country eq("Canada") or country is Canada or country == Canada or country = Canada, etc

Related issues #252 #301

[marfel]

I appreciate the discussion here, but implementing all this really looks like an epic endeavor, and I wonder if its really necessary for the average user? When I first stumbled on upon the dash_table package, ran the example and it took me a while to figure out how to specify filter expressions correctly. I found it not very intuitive.

Wouldn’t it cover about 95% of all cases, if any column (even numerical ones) could be filtered by simply typing a few letters or numbers into their filter field, which are then matched anywhere and without case. In this datatable implementation https://datatables.net/manual/styling/jqueryui there is even only one global search field! If you get too many results, you just add another word. Aside from that, the “<” and “>” operators for numerical columns can simply be achieved by sorting by the respective columns.

IMHO, simplicity, intuitiveness and responsiveness are more valuable than being able to “program” a filter with lots of conditions and operators. Perhaps such a simple, alternative filtering interface could be implemented quickly, as an option? The RStudio example is certainly fancy, but as an interface for the typical non-programmer user it’s probably a little bit over the top.

Just my two cents.

[chriddyp]

In addition to the NumExpr DSL, I’d like for us to consider how this would scale for additional datatypes beyond str and numbers, including:

• dates
• times
• IP addresses
• categories vs freeform strings
• numbers that could be considered strings (like zip codes)

Also, we should consider what the default “operator” is in the UI. Users shouldn’t have to always specify an operator like contains or eq or ==: they should be able to just type some text (e.g. canada or 15) and a reasonable filtering operation should occur.

Here’s a proposal that I worked on previously. Perhaps this can be updated to be more compatible with the NumExpr DSL

---

With the introduction of datatypes, the following changes could be made:

• string and enum
  • Default operator is still “contains”
  • >, >=, <, <= will filter alphanumerically
  • Regex will be supported
• number
  • Default operator is =, contains is not available
  • >, >=, <, <= will filter numerically
  • Decimal places will be supported
• date
  • Default operator is “contains” and will filter all dates at a lower resolution. For example:
    • Searching 2015 will filter all values with the year 2015, regardless of the month, day, or time
    • Searching 2015-10-05 will filter all values on the day 2015-10-05, regardless of the time
    • In this mode, it will not be possible to search just “January” across all years
    • >, >=, <, <= will filter by date, starting at the lowest date (e.g. > 2015 is equivalent to > 2015-01-01 00:00:00)
    • = won’t be supported. The user can search a specific date with the default and implicit “contains” operator