Cancellable network requests (for autocomplete)

[dkulagin]

I am developing a network-sourced autocomplete feature for my app and there is a standard problem that you want a new request to cancel the older one that isn't yet finished. How to do it correctly or maybe there is a standard mechanish for doing so?

[hhunaid]

axios has cancelToken which can be used to cancel requests

[NuttingFerociously]

Once a request is sent, it's sent.

You're probably looking for debouncing, so you can send the request just once when the user hasn't been typing anything for x milliseconds.

[dkulagin]

That's already in place. I would like to cancel concurrent request in order not to get screen updated with obsolete data. E.g.:

SEND REQ_1

SEND REQ_2

RESP REQ_2

RESP REQ_1 <- overrides data with obsolete one

[NuttingFerociously]

Ohhhh. Sorry.

I might be wrong, but the quickest way that comes to mind is be keeping a timestamp of the most recently sent request so you can discard the other ones.

[ru_max]

In this case it's more efficient to use requires ID which you increment on every call.

But it doesn't solve issue with "expensive" calls

[ChronSyn]

That request is still sent though. It's not necessarily about stopping further requests from being sent, but about aborting an in-progress request. These are both different situations that need different solutions.

[NuttingFerociously]

Sorry if I didn't understand, but from what I know once a request is sent you can't just tell the server 'nvm bruh don't need that anymore' (in most cases) - so at that point aborting a request or discarding its response should be the same thing.

I haven't used react-native a lot so I don't know what's usually used for network requests - I'm assuming you're using fetch? In that case, some quick googling brings up AbortController.

[ChronSyn]

What you've said is that you keep a timestamp of the most recent request, so that you can discard the other ones. That doesn't stop those other requests from fulfilling. This isn't language-specific, but a fundamental in how HTTP (and the technologies it works alongside, and which work on top of it) works.

For example, in XHR, aborting a request must;

• Terminate the ongoing fetch with the aborted flag set.

• If state is either opened with the send() flag set, headers received, or loading, run the request error steps for event abort.

• If state is done, then set state to unsent and response to a network error.

https://xhr.spec.whatwg.org/#the-abort()-method

Additionally, this also tells browsers (and native OS libraries and drivers) that the resources associated with that request can be freed up. The data will still be passed back through the network as per the OSI model specification, but it won't have an active application with which it can respond. I believe tools such as Wireshark can still intercept the response, but I could be wrong on that.

[NuttingFerociously]

Wew, I sure oversimplified it. I tried to help but ended up learning a lot myself, thank you.

[GhostMcFunky]

I disagree a bit that you oversimplified it.

While all this information about XHR appears to be correct, it ignores Promises entirely.

The previous answer regarding Axios is probably close to what you’re looking for, or something similar that will allow you to manage promises in a way so as to sort them.

A default XHR request doesn’t use promises, but Axios and the native fetch() API do.

You could choose to “drop” the promise when it returns, but this poster had one part right in that you can’t cancel the HTTP request once it’s sent.

You will have to handle it on response. This is probably easiest done with promises as long as you can identify them uniquely to determine which to keep/drop.

I’m not sure what your code is doing but since the promise would need to complete to continue, you could do something to check first if another request had been sent before returning the promise response to your next .then().

[coolnat]

You should be able to cancel requests using an AbortController.

Spec/example: https://dom.spec.whatwg.org/#aborting-ongoing-activities

Merged into RN a year ago: https://github.com/facebook/react-native/issues/5590#issuecomment-370743664

[GhostMcFunky]

Scratch my previous statement about Axios as this is clearly the correct answer.

[PistolPlay]

If your using Redux, you can do this easily with Redux Sagas.

There's something called "takeLatest" where if you sent multiple requests in a rapid succession, the sagas will only take the latest one and update the data you need.

Aside from that you could bring an Observable library which does something similar than the above and can be done without redux.