User should be able to drop a pending search request - Discussion

[eskombro]

When implementing a type-as-you-search experience, IMHO, the best experience comes from sending a search request immediately as the user types / modifies the input in the search bar. This implementation gives you some results as quick as it can, but it can be complicated in some contexts because multiple search requests can be running at the same time, and treating the responses can lead to a slow experience or to wrong results caused by the order in which those requests are sent.

Most workarounds must be implemented by the front-end developer, ignoring the requests that he/she doesn't want to show (but still using resources), doing an implementation which lets him/her cancel the pending requests, or worse, this can lead to introducing bugs or showing worng results!

Example:

a user searchs "cost"

1. User types "c" -> search("c");
2. User types "o" -> search ("co");
3. User types "s" -> search ("cos");
4. User types "t" -> search ("cost");

Sometimes request # 4 could be treated by MeiliSearch faster than # 3, and the front-end client will receive # 4's response and show it to the user, then receive # 3's answer and show it to the user. This leads to showing the user the results of "cos" but he wanted the results of "cost", an so it displays worng results.

In several cases a lot of requests shoudln't even be treated at all, or preferably, dropped.

Simple example of solution

A single example on how to solve this from the client side, it the method .abort() in AJAX.

when you do an XMLHttpRequest, this request can be dropped at anytime:

var xhr = new XMLHttpRequest(),
    method = "GET",
    url = "https://developer.mozilla.org/";
xhr.open(method, url, true);
xhr.send();

...

xhr.abort();

but we are not using AJAX so...

Proposition

Implement a method that exposes to the user the posibility of droping/aborting a search request.

More info or ideas on how to do it in this article

WDYT?
@curquiza @bidoubiwa @tpayet

[bidoubiwa]

I like your idea. We use fetch because we make it work on both browser and node environments. Where xhr only works on browsers. Fetch also has an option to abort.

I'm not sure I understand your solution proposal. What is "..." ?

[neupauer]

I just run into the same issue, so I've prepared a PR ( #636 ) that allows the user to add another configuration directly to the search request, e.g., signal.

So, the request can be aborted like this:

const controller = new AbortController()

const searchPromise = client.getIndex('movies').search('query', {}, 'GET', {
  signal: controller.signal,
});

controller.abort()

try {
  await searchPromise(); // throws AbortError
} catch (e) {}

Maybe in the future, it would be nice to have a mechanism that automatically aborts the previous search request, or returns something like this "Abortable fetch".

[curquiza]

I don't bring any solution, but just my experience with InstantSearch + meilisearch-js (via instant-meilisearch)

I don't have any issue, InstantSearch handles perfectly the requests order:

• despite the coc arrives after coco
• despite I force it to use meilisearch-js.

Maybe we can check how InstantSearch handles it.
I don't know if it helps for an implementation/solution, but at least it's written 🙂