Adds auto-suggestions + validation for manual filters

[Vigasaurus]

Changes

As per discussions in #1067

I probably should've worked on this is a different branch to keep the diffs normal, but eh, it's just built purely on top of #1067

Tests

• Automated tests have been added

Changelog

• Entry has been added to changelog

Documentation

• Docs have been updated

[Vigasaurus]

This is pretty much ready to go, I'll likely sprinkle some comments and cleanup across the React code, and fix the dialyzer-found issue, but otherwise this should be done as far as user-facing stuff goes.

[ukutaht]

Great addition, this makes the filters so much more usable!

Looking at the code, I'm always a bit wary about hand-rolling complex JS elements like a search-select box. Especially for handling keyboard input, highlight behaviour, accessibility, etc. I think the UX could be improved. Annoyances I ran into:

1. I don't think the grey background on the select input fits. I'd rather use an input with a border and white background which we have plenty of examples for. Also I would add an arrow icon on the right side of the input to signal that it's a select input.
2. The dropdown content isn't as wide as the input
3. The highlight styles are different depending on whether I'm cycling through the options with arrow keys vs hovering with the mouse. I think the highlight style should be consistent.
4. I don't like that the dropdown fades away when I'm typing or backspacing. It should stay open and only close when I pick a result, hit esc or click away.
5. When the dropdown stays open while searching on the backend, we should probably show a small loading spinner on the right side of the input while waiting for the backend to return results. If we add an arrow to the right, it could change into a spinner while fetching results.
6. I think it would feel a bit nicer if we returned more results from the backend and allowed the user to scroll in the dropdown body.

I would suggest basing the dropdown style off Tailwind UI which we've used extensively in other areas. They have styled dropdown components integrated with Headless UI to handle some of the nitty-gritty of select box behaviour. We can get a lot of nice things for free from Headless UI while still hand-rolling the async search behaviour.

@Vigasaurus if you think that's a reasonable idea, I can email you the code for a basic select box from Tailwind UI. What do you think?

[Vigasaurus]

1. I don't think the grey background on the select input fits. I'd rather use an input with a border and white background which we have plenty of examples for. Also I would add an arrow icon on the right side of the input to signal that it's a select input.

Makes sense, and yeah I think a down-chevron there could make it good and clear. I'm not sure I understand what you mean by the grey background though - you mean on hover, or for the input? I just took the existing styles from the datepicker for the hover, and for the signup form for the input.

2. The dropdown content isn't as wide as the input

Yeah whoops - that's just an oversight heh

3. The highlight styles are different depending on whether I'm cycling through the options with arrow keys vs hovering with the mouse. I think the highlight style should be consistent.

Yeah that makes sense - I had done it the other way to help the ambiguity if both were being selected, but looking at some other uses, that doesn't seem to the be norm and probably more confusing than helpful

4. I don't like that the dropdown fades away when I'm typing or backspacing. It should stay open and only close when I pick a result, hit esc or click away.

So you mean it should retain its suggestions while typing/loading? Or just show a mostly empty area with a loader?

5. When the dropdown stays open while searching on the backend, we should probably show a small loading spinner on the right side of the input while waiting for the backend to return results. If we add an arrow to the right, it could change into a spinner while fetching results.

Yeah I quite like the spinner being in the search box on the side, nice and cleanly - but then that poses a different question for above - re: dropdown sticking around.

6. I think it would feel a bit nicer if we returned more results from the backend and allowed the user to scroll in the dropdown body.

Yeah that makes sense

if you think that's a reasonable idea, I can email you the code for a basic select box from Tailwind UI. What do you think?

Yeah if you want to send that over that'd be cool - I quite like a lot of their stuff.

[ukutaht]

Makes sense, and yeah I think a down-chevron there could make it good and clear. I'm not sure I understand what you mean by the grey background though - you mean on hover, or for the input? I just took the existing styles from the datepicker for the hover, and for the signup form for the input.

Yeah I mean the actual input element.

I know we have some of these input elements with grey background still around. But I've been moving towards more standard looking input elements like the ones on plausible.io/register

[Vigasaurus]

Ah okay makes sense, I think I took the style from /login - anyways, if you just want to send over the Tailwind UI component when you get a chance, I'll get all the changes sorted out in the coming days.

[ukutaht]

@Vigasaurus FYI, I've reverted the previous PR from master since it's unfinished and I want to deploy some stuff.

[Vigasaurus]

New version of this coming very soon (just need some more testing + code cleanup, probably will update PR in <24 hours) - I'm using react-select to handle the search-select (the Tailwind UI/Headless UI one wasn't really a search+select, and making it behave like one would end up just as hacky as the self-rolled version). To use react-select, we needed to update to React 17 - but this is nbd, as 17 brought minimal breaking changes, none of which affect plausible.

imo, I think this version looks and feels really good (and accessible!) - I definitely still long for an easily styleable version of these styles of components, but I guess I just have to be okay with living in !important land.

This loader is the semi-standard 3-dots design, the screenshot just makes it look silly

[ukutaht]

Looks good to me!

At 84.8kb minified, react-select is almost as big as react-dom itself. Any way we could use a lightweight alternative that doesn't bloat our JS bundle as much? I suggested react-select-search earlier because at 9.2 kb minified it's about 10x lighter.

[Vigasaurus]

Yeah I gave react-select-search (and a lot of the others in the space are old/unmaintained - and suffer from the same issue as below) a serious shot, and honestly none of the others have a lot of the feature-set that react-select brings, between setting the input field externally (to allow searching on/modifying existing input), to having extremely powerful onChange events that make updating intermediate data (when a user doesn't explicitly pick a suggestion) actually possible.

With react-select-search 1. if a user started typing something and left the field, we'd have no way of saving what they typed (for example, if the page they want is /blog and all the suggestions are /blog/whatever), and 2. if they entered the edit filter action, they'd need to re-type/re-search for their filter, as on entry to the search-select, their input would always start as blank and making it start with the existing content is not possible from what I can tell. Also, with the specific import we're using I think react-select gets tree-shaken a medium amount.

To me, the UX that the alternatives provided vs react-select honestly warranted the larger size of the dep, because as you said, rolling it ourselves will almost always be bad for accessibility, and I think the lack of control on the others makes them really hard to use in this use case (or at least use well). Let me know what you think/if you think we should use the alternative anyways - but really I don't think sacrificing a pretty big chunk of UX for a bundle size reduction is that worth it (and we're still under 1MB not gzipped, and at about 260kb gzipped, anyways 🤷‍♂️)

[ukutaht]

Thanks for the thorough explanation @Vigasaurus . It all makes sense and I agree that the UX issues with alternative packages seem pretty bad. I have never found a search-select package that doesn't have its problems. Not sure why it's such a difficult component to build (not saying I would do a better job, just that I don't understand what makes it more complex than routing for example).

Tree shaking is great, I'll run it locally to see what the real bundle increase is. Another point is that the dashboard code is big enough now where I think code-splitting is warranted. Probably <10% people will open up the manual filter modal so as long as we start doing code splitting at some point we can minimize the impact of react-select for most users.

[Vigasaurus]

@ukutahts sounds good! Yeah search-select is always rough - I really hope headless UI makes a select-search at some point, I have to imagine their implementation would be nice. And yeah I think code splitting for all the modals down the line could be beneficial - having all of them have a slight load is probably not a big deal.

Anyways, this is pretty much at a finished state and ready for review now, I'll resolve the conflicts shortly though.

[Vigasaurus]

Closing in favor of #1121