codidact
Filters
I've reached a good point to stop working on further features for this pull request, I think. I've completed most of the stuff in #755 and #756, now it's just testing (maybe spin this branch up on the dev server for people to mess about with?)
Here are the changes:
Side widget
On the side of category feeds is the filter widget, where users can enter filter options. On submitting, the category will be filtered.
Search filters
Should be fairly intuitive. Filters the results of a search. NOTE: This is in addition to any search queries - if the user types "score:>0.6" and filters by a minimum score of "0.5", then it will only show results with score above 0.6. The reverse applies too.
System presets
System presets are initially populated by seeding. You can take a look in https://github.com/MoshiKoi/qpixel/blob/filters/db/seeds/filters.yml for the format
Note to Administrators: There's no UI tool right now to edit the system presets after the initial population of the database. If you want to modify them, they're just normal filter records assigned to the System user (user_id: -1)
User-created filters
If a user types in an option that isn't already the name of a preset, saving the filter will create a new filter for them. They can also modify an existing option by hitting save after changing a field.
Management
There is now a tab on the user page where users can create/edit/delete their filters.
Future Improvements
While not strictly necessary, there are some "nice to haves" I can think off for future work.
- Don't allow users to edit System presets on the client side. (I already do validation on the backend to make sure they have permissions, but this is just a nice UX thing). Right now, it just fails silently if they try to submit an edit to a System filter.
- Admin tool to edit System presets. I feel like they change rarely enough that doing without for now shouldn't be too much of a problem, and I already have a seed file which can populate it initially.
- Make filters that can't apply to a category greyed out (e.g., "min answers" filter option on a category with only Articles). This is a "nice to have", but it's not really necessary.
- Add tag includes/excludes to filters. This is somewhat involved from a technical perspective, requiring either changes to the tags API or a new API, so I'm deferring it.
- Add "favorite tags" option as a filter (relies on the above)
Thanks for all your work on this! This is great!
This comment is based on your comment (not on seeing it live). I would prefer that users not be able to redefine system filters for themselves; that would remove the ability to get back to the defaults. The system filters should be immutable, but users should be able to create new filters based on existing ones. What I'm imagining is: you choose a system filer, edit some properties (maybe your "positive" includes slightly negative, like a min of 0.45), and get a "save as" option where you specify a new name. That way you have both your version and the system version available.
This means there needs to be a place to type that new name. I don't care if that's part of the widget or a modal that comes up when you click the button.
On a different subject, can we put the filter parameters behind an expander, so you initially just see the selector for predefined filters, but you can click the expander to see the rest? I think most people, most of the time, will use a small number of filters and not want to see all the details all the time, which pushes other content in the sidebar down. (If my description isn't clear enough, let me know and I'll draw a picture.)
This comment is based on your comment (not on seeing it live). I would prefer that users not be able to redefine system filters for themselves; that would remove the ability to get back to the defaults.
It just silently fails if they try to redefine system filters right now.
On a different subject, can we put the filter parameters behind an expander
No problem 👍
That looks fine to me. You could actually make it a little more compact; "Filters" and "predefined filters" are redundant, so we could just have "filters", the selector, and the options behind the expander. The fact that there's a list means there are some predefined ones, after all. :-)
Can we only light up "save" if there are unsaved changes? We don't want to lure people into hitting that a bunch of times because they think they have to in order to use a filter.
Can we only light up "save" if there are unsaved changes?
If I actually select something, then it greys it out - though i suppose i could grey it out on initialization as well
It turns out tag filters were much simpler than expected; I just misunderstood the Select2 documentation
It turns out tag filters were much simpler than expected; I just misunderstood the Select2 documentation
It turns out my initial complexity assessment was actually not that far off... it was complicated in a different way
@ArtOfCode- , Moshi said in chat that this is ready for an initial code review. I see there are merge conflicts which obviously have to be resolved, but can someone can take a look at the code for any other issues in the meantime?
This test no longer succeeds due to a change in how search works:
https://github.com/codidact/qpixel/blob/8f36e90346ce1413cab8e6973620381a184c0153/test/controllers/search_controller_test.rb#L6-L10
Now, an empty search will return all posts. Should this method be changed to instead assert not nil?