New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Search Filter Improvements #1401
Conversation
This was originally disabled due to the UI work being incomplete. UI improvements have since happened which means we can turn this back on. This means users can search, with filters, and still have author/keyword suggestions based on the unfiltered search terms. `test stars:>1000` will show test packages with at least 1000 stars but will also show the "test" keyword.
This adds two new values to the search response. A "term" which is a subset of the query minus the filters, and "filters" which is currently an array of strings but this is likely to change in a future commit (just an empty array throughout). The search term is different to the search query as with a query of "test stars:>500 framework" the term is simply "test framework" and the filters is ["stars:>500"]. This is because in the UI for the search results, we want to show the term separate to the filters. However, we still need the raw queries for some parts of the UI (for example the user-input search box).
Filters are now shown as part of the search results page under the packages header.
I don't remember saying that! 😅 But I think this is 95% there already. I really like it. 👍 |
Just in case somebody reads this and thinks that Dave is like supremely evil, it was a joke 😅 Dave and I already agreed he was going to go through and do the UI on Discord ahead of me picking this up! (CSS is not my forte) |
This is looking really, really good. A few things I found while giving it a test tonight: No filter descriptions when no package results are displayedSo I had coded the CSS for the keyword results never expecting a situation where there would be a keyword result without any package results, which breaks the layout a bit! However, the bigger problem here is that without package results we're not seeing the filter description. I wonder if we should make it so this page always displays package results, or maybe just always display them if filters have been applied. Looking at the design for a search that matches nothing, it's OK, but it'd also be fine if that text were below the "Matching packages" heading. More to follow... |
Bug with
|
Pushed up a few small CSS tweaks but this is in great shape on the front end. 🎉 Thanks James! |
Appreciate the support Dave! There's definitely a known (expected) bug where it will return zero results if you only include a filter. That's just down to how the search mechanism works at the moment because it needs something to search and then just uses the filter to... well... filter down those options. Probably need to add something in there which lets it search all packages if the term is empty and filters are present. I'd maybe think tackle that separately though? As for the names as shown in the view, that's easily changeable. The createViewModel function just uses I was also thinking whether the date one wants to use a formatted value in the view model? So instead of "Last Commit is greater than 2020-01-01" it would be more like "Last Commit is greater than 1st Jan 2020". Again, something that could be changed purely in the createViewModel function (and why I made it a separate model). |
One reason I put this in here rather than as a separate issue is that searches without terms but with filters work on staging:
|
Yea, let's do that. I think I prefer option 3 out of all of the screenshots. How about you? |
I wonder if the fact we do a union now for keyword/author search is killing the entire search. That's the only change I can imagine causing that. I'll try reverting that in the morning and test. (First commit in this PR if you want to try) |
Let's write a test for it too to stop future regressions. |
Great idea 👍 |
Dave identified an issue where results would only be returned if there was at least one non-filter term in the search query. This was different to staging. I have fixed this and added a test which enforces it.
This helps to make it read a little better to the user.
Small UX improvement as it reads a bit weirdly.
Moves "no packages found" error down to under the matching packages header. This is a little more resilient to situations where there are keyword/author results (ignore filters) but no packages due to the filter.
Think I've now responded to all of the feedback/bugs. Should be good for a review/test |
I know I shouldn't be proud of this... but every commit passed on CI and that's a good feeling |
Little easier for the user to write.
As per chat with Dave, |
Current
Coming Soon
Future Ideas
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested locally and everything looks perfect!
I did just notice one tiny code clean up in my final review with the number formatter.
formatter.dateFormat = "d MMM yyyy" | ||
formatter.locale = Locale(identifier: "en_US_POSIX") | ||
formatter.timeZone = TimeZone(secondsFromGMT: 0) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have one for dates but I wonder if we should pull this out so our formatters are a little more organised? Equally, I could do this as part of expanding the filters to include last_active
. Noted for inclusion in #1390.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably makes sense to have a generic "search filter date formatter" for all filters which have a date input. My typical coding brain would say refactor that once there's a need, so in 1390, though. I'm happy to sort out that rebase+cleanup if need be once this gets merged through.
…tPackageIndex-Server into searchfilterstuff
This is an amazing feature, @Sherlouk. Thank you so much for all of your efforts with it. ❤️ |
Description
This pull request aims to add some finishing touches to the search filter capability which has been enabled in staging for quite a while now (sorry).
Specifically, this makes two changes:
There will be further improvements to search filters including the ability to filter by keyword and more, but this can could come after it's production-ised and certainly as a separate PR.
Association
Closes #1228
Closes #318
Related to #1396
Conflicts with #1390