Search page tech

[mmmavis]

UX wise

Current plan: We would like to have "search as you type". And it should search through all entry fields/meta (@xmatthewx @kristinashu correct me if I'm wrong)

Tech wise

Before we had pagination on Pulse API, I used to just get all entries by one /entries call and bind search input box's keyUp() event with client side filtering. The client side filter searches through all entry meta (not just title or description) and returns entries that have meta matched the search keyword.
Since now pagination on Pulse API is enabled by default, I wonder what the best way is to implement the search functionality.

• Challenge 1: multiple /entries calls have to be made in order to fetch all entries in the database
• Challenge 2: can we make use the /entries?search= param (note it currently searches through title and description only)? If so, does that mean we have to make a new API call on every keystroke? 😨

Maybe we should set some limitation on how search works. e.g., don't enable search-as-you-type. instead let 'Enter' trigger the search?

/cc @Pomax @alanmoo @kristinashu @xmatthewx

[alanmoo]

I implemented this on the Science site- basically I didn't search until the user had stopped typing for a fraction of a second as seen here. You could couple that with your existing behavior and the page_size parameter of a larger number to get what you're looking for.

Is the fact that search only looks in title/description a problem? What other fields should it search/exclude?

[kristinashu]

It should search everything, searching tags and people will be important.

I'm ok with having an Enter button if needed. Having one would also help clarify to users that they can share the url.

[mmmavis]

@alanmoo @Pomax I'm curious about what the better solution is - client side filtering or making /entries?search= API calls. I assume the latter but I wanna double check with you two as well.

[alanmoo]

I've opened a PR to support searching tags and creators. Keep in mind that tags specifically can be searched using the ?tags= query.

[Pomax]

challenge 1 landed in the form of a PR that lets you call /entries/?ids=1,2,3,... so with the list of ids you need to retrieve.

For challenge 2, this is an instance of "why not both" - use ?search= when you need to find entries and you don't know which specific fields to search in (it'll check title, description, tags, and creator fields atm based on alan's PR) - but if you have dedicated UI for searching specific fields like searching "in tags" or "from creators/publishers" etc. then you want the dedicated search route (which we have for tags and , if we need them for other fields we can add those in pretty easily).

[mmmavis]

This is done. We are now using Pulse API to get search result so I'm gonna close this ticket.

(note: here's a related followup ticket (for code refactor) that @alanmoo filed #361 )