Feature: Add filters using && or || in strings.

[benloh]

See #83

Adds ability to define string filters that use && or || in strings.

For example:

label [ contains ] "Ben || Joshua"     // matches "ben" or "joshua"
label [ contains ] "scuba && diving"   // matches "likes scuba diving in the Maldives"
label [ contains ] "scuba || swim"     // matches "likes scuba" and "likes swimming"
label [ contains ] "scuba || swim && diving"     // matches "likes scuba diving" but not "likes swimming" because it's missing "diving"

A few notes:

• The logic with "does not contain" gets a little screwy. I think it's correct, but you might check on it. It evaluates the expression, then returns the negative of the whole expression.
• While typing, a blank will evaluate as true, e.g. while typing scuba && will return true for any nodes that have "scuba", but typing scuba || will match ALL nodes since the blank is always true.

[jdanish]

Contains works great. Does not Contain is a bit weird.

This || statement works right on "contains" but on "does not contain" misses the second node.

And on the && ... it seems the reverse - gets one too many on the does not contain. Almost like AND and OR are flipped with does not contain?

Also, the field has the same issue the search used to. If you type Books && Burning, then place the cursor to change && to ||, press delete and it now reads Books & Burning and the cursor is at the end.

[benloh]

does not contain logic

Ah, the logic was flawed. I was applying the "does containt/does not contain" logic to subclause. Please try again and see if this fixes it. c1ec735

the field has the same issue the search used to. If you type Books && Burning, then place the cursor to change && to ||, press delete and it now reads Books & Burning and the cursor is at the end.

This has been fixed with 5342dec

[jdanish]

That works, thanks! Helped me notice another (maybe new?) issue though. If you type a filter for a string, and then switch contains to --, the filter text should be removed, right? It does not. Then if you switch -- back to contains it is not recognizing the text immediately. Though if you add to it by a letter, it then functions as expected.

[jdanish]

I also just noticed that markdown fields do not appear in the filters, but would assume they appear / use the same functionality as strings. Sorry I didn't catch that before.

[benloh]

If you type a filter for a string, and then switch contains to --, the filter text should be removed, right? It does not. Then if you switch -- back to contains it is not recognizing the text immediately. Though if you add to it by a letter, it then functions as expected.

Sorry about that. We actually had that fixed previously, but then another bug was introduced where the cursor position was being lost with state updates (Kalani's issue from a few weeks ago). This should be fixed now.

I also just noticed that markdown fields do not appear in the filters, but would assume they appear / use the same functionality as strings. Sorry I didn't catch that before.

Oops. Good catch. Markdown fields just use strings to work. But I had to explicitly add support for filters. Should be fixed with cb3e3d0

In addition:

• Re-layout Search input field so the "New Node" button will wrap on narrower screens. b174b85
• Re-order Number filter operators so that the more commonly used "=" appears first. 6c52246
• "Clear Filters" button now properly clears operators AND values in filters. bb878d2
• Refactor "FiltersPanel" so that the filter definitions state is retained when expanding or collapsing the FiltersPanel. 399a101

[benloh]

@jdanish Did you want to add help text in the "More...> Help" panel for using && and || in filter searches? Should I leave that to you?

[jdanish]

Debating, so leave it to me. Thanks!

[jdanish]

@benloh looks good - go ahead and merge when you are ready!