UI filter builder

[WithoutPants]

Replaces the add filter dialog with an edit filter dialog. This allows adding/editing filter criterion all at once:

• text fields have a confirm button to modify the value
• current filter is shown at the bottom, with an extra option to clear all criteria if there is more than two criteria
• criteria with current values have an x next to their entries which allow deleting the criterion
• criteria with options are presented as a list of checkboxes

Mobile view presents the criteria list only, then shifts to the criterion editor when a criterion is selected, with a back button to return to the criteria list.

Also adds the criteria count as a pill to the filter button, and adds the Clear All button to the main view as well.

Closes #949

[cj12312021]

I encountered this bug that wouldn't allow me to specify another filter. Anytime I used the drop down it would send me back to the performers filter.
https://user-images.githubusercontent.com/72030708/223875732-e8604af8-5a75-4d3a-80f8-137a830dbe34.mp4

I also noticed that the submit button is inconsistently placed on a few of the filter menus. It's not clear if this was intentional:

[WithoutPants]

Criterion selection bug should be fixed. Thanks for the report.

Yeah, there's a style discrepancy there currently. I wanted to add the confirm button to the input control, but this breaks down when you have a between modifier and need two fields.

I can move it out into a separate button to be consistent, but I want to confirm that this is the best approach from a UX point of view.

The alternatives are:

• update on keystroke - this is kind of a waste of rendering, especially when rapidly typing into a field. We could debounce it slightly I guess
• update on blur - the problem with this approach is that it's not intuitive to the user how to confirm a value. They will type in a value, not see any confirm button, and wonder why the filter hasn't updated.
• reposition the confirm button somewhere else?

I chose this solution based on playing around with the ebay filter UI.

[cj12312021]

Sorry, I forgot to get back to this. That makes sense. Yeah, I was leaning toward having the button on the input field, but I see that challenge with that when dealing with the between modifiers. I think consistent placement would be best, so the user always knows where to find the button without much thought. So perhaps the button could just stay below the input fields.

I also confirmed that your latest push addresses the issue I mentioned earlier.

[cj12312021]

I wonder if a design like this might make more sense. The current design leaves a lot of unused space:

[WithoutPants]

I agree, it looks better imo, and is more consistent with the mobile view:

The applicable element is scrolled into view when clicking on a criterion from outside the filter dialog. This behaviour is not triggered when clicking on the pill from inside the dialog, since I couldn't get the scrolling function to consistently scroll to the correct position.

[xx790]

Will this UI work well when #2692 gets addressed? (We need multiple filters on the same property like tags)

[cj12312021]

I agree, it looks better imo, and is more consistent with the mobile view:

The applicable element is scrolled into view when clicking on a criterion from outside the filter dialog. This behaviour is not triggered when clicking on the pill from inside the dialog, since I couldn't get the scrolling function to consistently scroll to the correct position.

This looks a lot better and functions as I would have expected.

[cj12312021]

I do think all the selectors could continue to take the full width as they used to. For example, the modifier selector for play count in your screenshot took up a little under 1/3 of the width where it used to take up the full width.

[WithoutPants]

Will this UI work well when #2692 gets addressed? (We need multiple filters on the same property like tags)

I don't think it will preclude it from working. The UI design can be iterated on as part of the work on that anyway.

[DingDongSoLong4]

In terms of looks, this is amazing - infinitely better than before.

I do think the confirm button is a bit annoying though, I can definitely see myself forgetting to click it and then losing the filter after clicking Apply. It also looks kinda out of place on its own line, and is basically just an extra unnecessary click imo.

I get the hesitance to update while typing, but do the extra rerenders really make that much of a difference? Even if debouncing the updates is necessary, I think that would be a much nicer experience than having to confirm each field manually.

Three other minor issues I found:

• For the Stash ID filter, if you enter an endpoint first and then move on to the ID, the endpoint is cleared.
• For any of the hierarchical inputs (Studios, Performers, etc), if you select a modifier without adding any values, it will still add an empty criterion to the list.
• For the timestamp filters (Created At, Updated At), the placeholder text uses 'HH-MM', which should be 'HH:MM'. This actually seems to have been an issue before as well. The backend is also returning all scenes here instead of an error for invalid input, which can be fixed separately at some point.

The Stash ID issue actually ended up being fixed as a byproduct of the quick and dirty change I made to get a feel for the dialog without the confirm button (basically just replace all the setValue calls with onValueChanged and get rid of the value state).

And then the last improvement I can think of would be to validate the date/time/duration/etc inputs, but that can definitely be done later in a separate PR.

[WithoutPants]

Thanks for the feedback.

I've removed the confirm buttons, the value is now updated as typed. Stash ID and hierarchical filters should be fixed, and I've fixed the placeholder text on the timestamp filter.

[DingDongSoLong4]

Lovely, looks great. I'm still seeing the hierarchical issue for Studios and Tags though, the fix seems to have only affected Performers and Movies.

[WithoutPants]

Thanks, the other criteria should be fixed now.

[echo6ix]

I'm having an issue where the country results get cropped

• Custom CSS disabled
• Chrome v111

[echo6ix]

First, I think this is a big improvement, and adding a badge counter to the filter button is a great idea. My only feedback regarding that badge counter is the following:

1. Badge color. Red is used as a color to denote destructive actions or cancellations throughout Stash. A variation of bright blue might be better for this badge. Off the top of my head, the --info color defined in the CSS would work.
2. Badge placement. Placement seems a little awkward to me here. I think the above (and below) example from Github would work a lot better