Aborting and intercepting requests using fetch API
Probably an ajax request is one of the things that we must do when we are developing website applications. But we had a complex API during years.
But, in ES6 (ES2015) browsers introduced Fetch API (THANKS 🎉) and… we created some articles, some POCs and some small apps with fetch, but we kept using libraries on real projects.
And why? Probably because Fetch doesn’t have all the features that we need, features like interceptors or abortable requests.
But, wait, with Fetch is no so difficult to use these features.
Sometimes we need to abort a request, because we don’t want to finish it, and we don’t want to create unnecessary work for the app.
For example, we open a page that has to show to us a list of items, we create an ajax request to get all the data that we need.
But what if before having the results of this request we change the page? The request will continue until the end, but the user will never see the data.
Another example could be when the user triggers an action and before it finishes, he decides to cancel it. In some scenarios could be useful to also abort the request.
How it works?
First of all, we have to create a controller, this controller will have only one method called
abort() this will trigger an event that signal object can handle.
Note: You only need one controller for each group of requests, probably with one controller for the whole API could be enough, but remember that every time that you call to abort() you must create a new controller. Probably to have a small service or wrapper will be a good idea.
If we want to abort we have only to do that.
If you want to play with the code, you have here an interactive example.
Using AbortController with Fetch
Finally, we have only to use all of this with Fetch API. The API is ready to use a signal to abort the request, you have only to pass the signal as option.
And, the corresponding example is here.
Meanwhile is not supported by all the browsers (only the modern ones) you can use the polyfill.
Interceptors are also a very common pattern that we usually need to use in our websites and applications.
These are the two better examples where I use interceptors:
The first is working with Sessions in FrontEnd, when any of our requests receive an error
401 that means that the user is unauthorized, I want that when this happens the user must be redirected to the home page.
And the other could be to log what is happening in our request.
To work with interceptors, I like to use the library called
fetch-intercept that is the most similar to have a native implementation of interceptors.
There are basically 4 methods to handle all the different states:
requestis going to be called before each request, here you can add a
Bearer tokenfor example.
responseeverything was ok, no worries.
requestErroris the request was wrong, you can
logthe error, to have analytics.
responseErrorsomething bad happened, probably you want to
logand if the error code is
401yes, do you remember this, we have to redirect to the login page.
You can play with the example on this jsfiddle.
What do you think about this two features? For me are very powerful, and I think that we should use in all our projects if we are not using them yet.