case insensitive filtering

[chriddyp]

As discussed in https://community.plot.ly/t/case-insensitive-filter-search-for-dash-datatables/26258

[dmt0]

We can do something similar to what PowerShell is doing - just prefix every operator with a - character to indicate that filtering is case insensitive. So we would have:

-contains
-eq
-=
->
->=
-!=
etc.

Other option would be to introduce one more operator/reserved word, like ci, followed by a space, that would precede the whole string to indicate that filtering is case insensitive.

[alexcjohnson]

How well-known / widespread is the precedent of - prefix? It seems weird to me, looks almost like it's negating (ie inverting) the operator.

Functionally each insensitive comparison would have to work as a single operator, since it affects both sides of the comparison - so I'd prefer a prefix instead of a separate word. How about the letter i? So icontains, ieq, i>= etc?

[dmt0]

I searched the web a bit for any kinds of precedents and all I found was this weird PowerShell thing and something from mysql that wouldn't translate well to our problem. So there doesn't seem to be any standard case operator out there, we are perhaps free to invent one :)

[chriddyp]

Does it make sense to make case insensitive the default?

For =, maybe we could do case sensitive with quotes e.g. "Product" vs product.

That leaves out case insensitive contains operator.

[alexcjohnson]

I think whatever we do should be more explicit than quoted vs unquoted - anyway when we translate entries in filter inputs into query strings or structures for callbacks to use this distinction will be lost. And if/when we get to more complex semantics, having the case sensitivity determined by the value one one side will be a limitation; it's really an attribute of the operator so should be set by the operator.

Perhaps we could have a column option (with table-wide prop to set the default for all columns) to use case-insensitive comparisons? I'm not sure I'd want it as the default, but perhaps could be convinced.

If we want to give users complete flexibility though, even a column that's set to case-insensitive should have a way to filter the other way, and vice versa. I suppose one way to do this would be to have three flavors of each operator: default (based on the column/table setting), sensitive, and insensitive. Could be contains, scontains, and icontains?

[Marc-Andre-Rivet]

An interesting flexibility we have here imo is that the syntax we come up with can be specifically tailored for the column filters. For example, (s/i/‘’)contain can exist in the full syntax but be expressed through prefixing or appending /i /s in the column filter - or a ui toggle equivalent later. We can translate from one syntax to the other.

[dmt0]

Here's what I propose for the UI:

There's an indicator on each column as well as on multi-column filter. The indicator will look like so: Aa and get a border around it whenever the filter is case sensitive.

Multi-column filter is not part of the table, so column indicator will depend on both - global prop and the per-column prop.

So if table is set to case-insensitive - all columns will show that they're case insensitive. Setting one column to case-sensitive will just set that column to be explicitly case-sensitive.