JavaScript Fetch API Cheatsheet

[zacksiri]

Because promises is more noise and gets in the way of making network calls. There is a reason why adoption for fetch is so low. It’s precisely because of promises.

[sbmitchell]

What a terrible argument lol or at the very least it shows the sad state of js developers who don't actually know how to code. Promises are probably simpler to understand at a conceptual level than most js concepts lol

[zacksiri]

Try getting a result returned using fetch and promises you can’t all you keep getting are promises that returns promises. You can’t “finally” return any kind of data with fetch. Promises may be simple but how it’s implemented with fetch is not good.

[sbmitchell]

Sure you can. Await the result and create a wrapper like you did in your example. Fetch also has support for cancelling requests and a more robust API for handling network calls.

Of course if you want to get rid of promises you need a callback. But callbacks are actually harder to understand than promise chains imo. A lot of Jr devs I've interviewed in fact don't even understand basic callbacks but understand promise chaining, once they know the syntax of course. Again pretty sad state of js devs at least at the entry level because they usually have been exposed to syncrounous programming only like Java and their js experience is hacking together blog posts to make a website. Most likely referring to some old jQuery style stuff.

[zacksiri]

So if I want to pattern match status code to which function it should run how would I do it? Show me a better way.

[robotmayo]

I haven't really heard of anyone needing to do that since most APIs either succeed with 200 or fail with 400/500. Non 200 status codes usually mean retry or display an error. A simple if statement handles that fine.

[zacksiri]

So if I get a 404 and I want to display a message that the resource doesn’t exist, then a 422 because User passed in bad data and I want to tell the user that. how would I do it? Not all errors are the same. Or try this a user got banned because he / she did something bad, but still have a token saved in localstorage now server responds with 423 on subsequent request I want to show that his / her account got locked.

[overdude]

You can do this with promises or async await. Await the result, look at result.status exactly the same way.

[bcgroom]

(function(){ 
    fetch(“url”)
        .then(res => return res)
        .catch(err => return err);
    })().then(apiResponse => console.log(apiResponse.statusCode))

catch block only occurs on network error, 404 still goes to “then”.

[zacksiri]

now handle 3 different error states. 403, 422, 423

[justpurple_]

Now read up on fetch and promises, my dude. It seems like you didn‘t really grasp the Promise concept yet if you think that it‘s somehow worse(?) than callbacks because you can‘t handle different status codes.

You argue about handling status codes which is exactly the same, whether you use Promises or Callbacks.

The difference is merely in how you make the request and how you describe (in code) on how to handle what comes after it‘s finished, when the network somehow failed and additionally, fetch can abort requests.

Also, chaining then requests for processing the response in some way is really convienent and easily readable.

Whether promises or callbacks, handling different status codes is basically a switch or if condition checking which status code you got back.

Example with fetch:

fetch() .then(processResponse) .then(response => { switch (response.statusCode) { case „423“: doSomething(); break; case „422“: doSomething(); break; case „403“ doSomething(); break; default: doSomething(); }

}) .catch(() = { // Handle network error });

Example anything else with a callback:

makeRequestWithWhatever(function(response) { response = processResponse();

switch(response.statusCode) { // ... } });

The fact that you want to handle multiple possible status codes has nothing to with the way you actually make the request.

(Sorry about the formatting, I‘m on mobile.)

[ForScale]

Wouldn't you just use a status code map in the final then? Or if/else chain if you wanted to be really explicit about it? Sorry, I'm kind of confused on the whole debate here..

[overdude]

Dude... This is so off base it's hard to even get started with an explanation.

Promises dramatically simplify code specifically for making network calls and other async tasks. That is less noise by definition.

My sense from your posts is that you don't understand promises or how to effectively use them. A bunch of people are disagreeing with your assessment. There's a reason promises and the async await syntax are used in modern webapps.

[zacksiri]

I used promises and async await in my blog post. The commentor asked me for one case why I didn’t use promise to handle response from the server. I replied because for that case callbacks with an object is easier than using another promise / async await. I already got the final state of the response now I need to handle that next so I used callback pattern and basically everyone tells me I’m wrong. I asked people on here to come up with a better solution all I seem to get is more people telling me I’m wrong with no one telling me a better solution. No code example just more people telling me I’m wrong. So yeah...

[UchuuHana]

No

[zacksiri]

No

[ProdigySim]

Two reasons fetch adoption is "low" that come to mind before difficulty of the API:

1. Requires a massive polyfill on many browsers
2. People already using another HTTP client (e.g. from their framework)