search: refactor to expose context and settings before processing args
Created by: rvantonder
(Sigh, typing this up again)
Before this PR:
- We did some work parsing queries and processing pagination requests in the
Search
function before calling any of the search resolvers implementing methods:
type SearchImplementer interface {
Results(context.Context) (*SearchResultsResolver, error)
Suggestions(context.Context, *searchSuggestionsArgs) ([]*searchSuggestionResolver, error)
Stats(context.Context) (*searchResultsStats, error)
}
The problem is that we don't have a handle to context
in the Search function, meaning that adding any flags to control parsing, or query options, or pagination (or things we might add in future) is ugly and hard to add to user/org/global settings.
After this PR:
The logic we do in Search
is moved to a common function setup(ctx)
that is called by each of the three methods above. But now, we have a handle to ctx
and can case out on settings before parsing (or anything else). This had some follow-on changes (which are generally nice):
-
No need to have alerts implement the
searchResolver
interface (which was previously necessary when returning alerts from theSearch
function). Now we can just wrap in in aSearchResultsResolver
like we elsewhere. -
We can remove references to
originalQuery
and reference search args directly, which is propagated in the resolver now. -
Allows for a user/org/site flag, see #12088 (still WIP)
Open question: I'm not sure that setup
is a great name for this method. Alternatives?