Aborting and intercepting requests using fetch API

Image for post
Image for post

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.

Thankfully, we’ve got a lot of different libraries that help us to don’t have to think a lot in xhr: jQuery or axios are probably among the top libraries to work with ajax.

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.

Aborting requests

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.

Intercepting requests

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:

  • request is going to be called before each request, here you can add a Bearer token for example.
  • response everything was ok, no worries.
  • requestError is the request was wrong, you can log the error, to have analytics.
  • responseError something bad happened, probably you want to log and if the error code is 401 yes, 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.

Written by

Breaking projects at @PlainConcepts during day. Dreaming at @HelpDev_ , streaming at @JavascriptIO and learning at @NeedU_org over the night • Web GDE

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store