For searches with no results, retry if Swiftype thinks there is a spelling error

[danswick]

Adds to the default Swiftype connector configuration to handle possible spelling errors in search queries. The Swiftype API supports a "spelling" option, but it is not supported out of the box in the elastic search-ui library we use for our search. However, search-ui has a beforeSearchCall hook that can append arbitrary options before a search call is made.

There are three options for how we could handle spelling issues:

1. strict: Returns a spelling correction value when there are no results matching the submitted query
2. always: Returns a possible spelling correction even if there are query matched results
3. retry: Automatically retries the search request with the spelling corrected value if there are no results, but there is a spelling correction. Note that retry can lead to a slight decline in performance as a result of running 2 queries.

retry is going to be the simplest to implement today to improve users' experience with empty search results. There may be a performance hit as noted in the Swiftype notes, but 1) the retry happens entirely on Swiftype's side and is opaque to the end user 2) Swiftype is already a little on the slow side and the difference doesn't appear to be significant during local testing 3) a retry only ever happens for queries that wouldn't have returned results anyway, so I'm not sure any performance downside is terribly meaningful. The one significant risk with this option is the potential to return nonsense for some queries.

strict is probably the best bet to contain any performance issues that might crop up while giving users a bit more control over what they see. With this option, Swiftype will return spelling suggestions when there are no matching results, but it only returns the suggested new search term and doesn't include any actual results. This means we would need to build out some UI to 1) present the suggestion to the user and 2) give them the option to try the suggestion instead.

always could be useful if a query only returns a few (maybe less than a page?) results. In those cases, we could do something vaguely Google-esque and say, "Your search only matched a few results. Did you mean blah? Here are some matches for blah:" while falling back to the suggestion right away if there are 0 matching results. I noticed that some typos return surprising results, especially if the query contains multiple words. However, Swiftype does a pretty ok job here! For example, if you search for "access toked," the default response will just include any page that scores high for access and it will just ignore toked. However, Swiftype will also include a spelling suggestion if it doesn't have a high confidence in the results. For the "access toked" example, even though some results were returned, it still adds spelling_suggestion: { text: "access token" } to the result's info property.

I strongly favor retry for now. I think it will be great to make an improvement now and come back to other options later if we get more feedback or just want to iterate on our search UI.

Here's an example of how a typo search might work with retry:

1. User tries to search for "geocode," but accidentally types "geocord".
2. We send the following request to Swiftype:

{
  "engine_key": "abc123",
  "per_page": 10,
  "page": 1,
  "facets": {...},
  "q": "geocord",
  "spelling": "retry"
}

3. Swiftype finds no matches for "geocord," but thinks the user might mean to type "geocode." The following results are sent back:

{
  "record_count": 10,
  "records": {...},
  "info": {
    "page": {
      "query": "geocode",
      "current_page": 1,
      "num_pages": 13,
      "per_page": 10,
      "total_result_count": 127,
      "facets": {...}
    }
  },
  "errors": {}
}

How to test

• Pull down this branch, install, and npm start.
• Open the test cases page, navigate to the Search component, and type some mangled search terms. Geocord, spprt, morker, "gs jl", etc.

QA checklist

• No errors logged to console.
• Accessibility score in Chrome DevTools Audit/Lighthouse is 100% with Lighthouse version: 7.2.0.
• Component is accessible at mobile-size viewport.
• Component is accessible at tablet-size viewport.
• Component is accessible at laptop-size viewport.
• Component is accessible at big-monitor-size viewport.

Open the test cases app locally on:

• Chrome, no errors logged to console.
• Firefox, no errors logged to console.
• Safari, no errors logged to console.
• Edge, no errors logged to console.
• Mobile Safari, no errors logged to console.
• Android Chrome, no errors logged to console.

Before merge

• Add entry to CHANGELOG.md to describe changes.
• If updating dependencies or creating a release, run npx browserslist@latest --update-db to update the browser data and commit any changes to package-lock.json.

[katydecorah]

Lurks gourd to me!

(Seriously, thanks for explaining the options and why you chose retry. This will be a huge improvement.)