Objective Search UI

[wwall3r]

Ideally this will be used in both game creation, potentially game edits (I think we should allow add but not editing the entire set? Or maybe just only allow additions after the first board is created for a game), and admin for objectives.

It needs to be able to add filters for:

• tags
• author
• set name (see #7)
• objective name

And the state of the search should be entirely stateless as part of the URL, so that the URL can be shared with others and show the same results.

I think generally it should look like this:

  < ... search >
  < popular, trending, or recent tags as pill buttons>

When the user does text search, we do two search results: one for objectives and one for tags. The tags replace the popular/trending tags with the pill buttons for tags matching that text. The objective search runs with any selected tags, author, and set name along with a text search on the objective label itself.

The objectives and their associated set name, author, and tags are listed in rows, with those items clickable in order to add them to the search.

Need to get the index right on both objectives and tags tables such that this is fast and can handle heavy load.

[wwall3r]

@jaystile Here are some notes from a little research tonight:

• Basic Full Text Search docs from Supabase
• Potential full text search over multiple related tables (objectives.label, tags.label, objective_packs.label, and user_profile.display_name) has performance concerns, and top answer here covers various solutions

Basically, we can either go down the "full text search over multiple related tables" route, which gives you more of a google-like experience, or we can do something where the terms are more qualified like GitHub ("text author:wwall3r pack:running tag:example"). Given decent UX, users wouldn't necessarily have to know about typing those in.

EDIT: Separate UX thought, there's no particular reason the search has to only return objectives. You could initially run 4 searches from just a text query: packs, objectives, tags, and authors (users who have added objectives/packs), and clicking on anything but an objective result lets you drill the search down.

[jaystile]

@wwall3r , I read through the docs. I don't have a preferred solution. The things we want searched:

• objective.label, objective.description
• tag.label
• objective_pack.label, objective_pack.description
• user_profile.display_name as referenced from objective_pack.user_id

Brainstorming:

• Query blast: Execute four queries. Each table gets enabled with textsearch indices
• Materialized View: Two columns: objective_id and searchterms. searchterms is a union of all the data that we want to search. Materialized views are recalculated on each change and exist on disk.
• Objective Search Column: Whenever a tag, objective_pack is created recalculate the searchcolumn in the objective (very similar to materialized view but in the objective table for colocation)

[jaystile]

@wwall3r I created a proof of concept for materialized views if you wanted to play around with it.

The deficiencies I found:

• Partial words will not return: querying for 'ru' will not return 'run'
• CompoundWords are special and will not be returned without the full term search 'Jason' with no results, 'JasonTheMighty' has results
• Stop words are common terms that will not be added to the lexemes. Sorry Will no one is going to search your for objectives... will they?

Overall, I think it will meet our needs. The issue is that if you want to know which tags and packs an objective belongs to, you'll have to join in that data before coming back from the search.

[wwall3r]

Partial words will not return: querying for 'ru' will not return 'run'

I'm fully on board with that.

CompoundWords are special and will not be returned without the full term search 'Jason' with no results, 'JasonTheMighty' has results

This is fine.

Stop words are common terms that will not be added to the lexemes. Sorry Will no one is going to search your for objectives... will they?

This is where I was thinking that something more like GitHub's issue search might be better, like specifying user:will or @will. That could be as simple as prepending an @ onto the user_profiles.display_name when putting it in the index, correct?