jQuery is great. Not only for its famous DOM manipulation but also for its extended functionalities, ajax is one of them. But when you use some libraries like React, you won’t need jQuery at all. But still you need to make an ajax call, how to deal with it?
There are tons of libraries which you can use. But just a special one you should pay attention, Fetch API, a living standard, and will someday be implemented by every modern browser. In fact, the latest version of most browsers have all supported this API. Including Chrome(Desktop/Android), Firefox, Opera and Edge. Let’s say how fancy it could be :) We’ll see it in a high abstract view first, then break into pieces. So you can learn it in a very fast pace.
aha, just that easy, right? Please notice the following details, they are the foundations of this API:
- previousJSON in the second then()
There are mainly 2 ways to create this request object:
- request object
The ‘URL’ way is easy, you just pass the url as a string, not only for the json, but you can request a image, then later deal with it as a blob!
The ‘request object’ way is just a more complete way to form your request, you can modify every parameter of this request, then pass it into
var myRequest = new Request(
If you have tons of headers to set, there is a
Header() object you can use:
var headers = new Headers();
Before dive into the response object, let’s see this check first:
if (response.ok) , you may guess this is a new way to handle error, but then you find in the above block there is a
.catch() function at the last of the chain. Then you get confused… In fact,
okis a read-only property of the
Responseinterface which contains a boolean stating whether the response was successful (status in the range 200-299) or not.
Yes, only 200-299, even a 404 is not in this scope. If you need to detect it, you can use the following property to retrieve this value:
var httpStatus = response.status;
Since this is the most important object that we developers will deal with all over the day, Let’s take a close look at how many fancy stuff are await us :) If the name is not that self-explanatory, I will add some comments there.
- Response.status //return 200 etc.
- Response.statusText Read //return OK for 200
- Response.type //return basic, cors, opaque, error, etc
- Body.bodyUsed //a Boolean that declares whether the body has been used in a response yet.
- Response.error() //return a new Response object associated with a network error.
- Response.redirect() //Creates a new response with a different URL.
The following method comes from the body object, but since the response object implements its interface, you can use it on the response object too, all they do is just taking a response stream and reads it to completion. Then use the according type to return it.
A side note: The request object implements these interfaces too, feel free to use them.
In fact, like middlewares in node.js or ASP.Net Core, you can chain a lot
then() methods here, and they will all return a promise object, then you can lots of functions here to decouple your logic. It means,
every value you returned from a
then()method, will pass into the next
then()method as a parameter. And if you use the above methods to return, the return type will be Response. Great, so you can take advantage of the fancy things above again.
This is why I declare the parameter in the 2nd
then() as a previousJSON, just for a hint. Let’s review the previous block. I think now these make more sense now.
As I said, nearly all modern browsers have implemented this elegant API. But since we can’t ingore IE, the polyfill library comes into play. Roughly speaking, this is a 3rd party library which implements this Fetch API following the standard, and deal with the underneath browser compatibility for you. So you can use them now, when the final day comes, you just delete this library and everything will be fine. Isn’t that fantastic?
Just click this GitHub link and use it, today!
Or you can install via npm:
npm install whatwg-fetch --save
Some of you may wonder why this library has such a strange prefix. Here is why:
The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors.
Yes, they are the standard! And they even list
fetch() as a second line of their main focus standards. And you can check the full details of this API here.