If you're a web developer, you've almost certainly
used XMLHttpRequest.
But without a library wrapping XHR, it's a pain in the butt.
It requires a bunch of setup, needs
calls to both open and send, and worst of all, the name.
Why does it even have XML in the name?
Chances are, you didn't use it to transfer XML.
So now we have a new modern design API
for network requests, Fetch.
[BALL BOUNCING]
The new Fetch API makes this much easier
with a simple, cleaner API that separates
the request from the response and uses
Promises to avoid the hassles of callbacks.
So let's go Fetch some data.
The Fetch API is pretty easy to use.
Simply call Fetch and provide the URL that you want to Fetch
and optionally any parameters that you need to provide.
Fetch then returns a Promise with the response object
that contains details about the response,
such as the status code, headers, and other metadata.
Plus, it provides access to the response stream
with an understanding of what type of data it is.
For example, since my data is JSON,
I'll ask for response.json, which returns
a Promise to get that data.
If you haven't guessed by now, Promises
are integral to the way that Fetch works.
If you're unfamiliar with Promises,
check out this post on HTML5 Rocks.
One of the neat things that you can do with Promises
is to chain them.
For Fetch, this means that you can share logic
across different Fetch requests.
Instead of checking the status of a response
with an inline function, I'll create a separate function
that checks the status code and returns a Promise.
I'll do the same thing to get the JSON object
from the response stream.
Now, I can simplify the Fetch request quite a bit.
I'll make the Fetch, check the status code
to make sure I got a 200 OK, get the JSON,
and then handle the result. If anything
goes wrong along the way, I can catch the error and deal
with it.
In addition to the request URL, you can also
pass Fetch a set of options.
With the options object, I can set the method used,
add HTTP headers, set the body of the request,
add credentials, even control how cross-domain requests are
handled.
For example, to use Fetch to post the results of some user
input along with an OAuth token, I
would use "method" colon "post," "headers" colon
"Authorization," followed by some ugly string,
and "body" colon the data that I want to post.
Making cross-domain requests with Fetch
uses the same policies as XMLHttpRequest,
verifying that the correct CORS headers are
present before returning the Promise.
It sets the response dot type to CORS,
indicating it was a successful cross-domain request.
But if the correct headers aren't set,
then the Fetch will fail, and you
won't be able to access the status
or read the data returned.
I can also tell the browser specifically
how I want it to handle cross-domain requests with one
of four mode options.
I can set mode colon same-origin to ensure
that only requests made to the same origin are possible.
Anything else is rejected.
I can set mode colon cors to allow requests
for assets on the same origin and on other origins, which
return the appropriate headers.
I can force preflight checks to always occur with mode colon
cors-with-forced-preflight.
But there's also a mode no-cors to get data from a server that
doesn't support CORS.
But this results in an opaque response.
You won't be able to read the data returned
or view the status of the request.
This might seem odd.
But when caching results in a service worker,
this is a very helpful feature.
There you go.
Fetch is pretty easy to use.
There are still a few gotchas, though,
that you need to be aware of.
Like all new features, it's not available everywhere yet,
but support is growing quickly.
So be sure to use feature detection to see if it's there.
If not, you can use the polyfill.
The other big gotcha is that you can't cancel a Fetch request.
But it is in the spec, so it should land
at some point in the future.
So go give Fetch a shot, and save yourself a few callbacks.
[MUSIC PLAYING]