The Fetch API is not that new and most developers have used it at some point to retrieve resources from a server, but do you really know how to han...
For further actions, you may consider blocking this person and/or reporting abuse
Amazing post!
I always tend to use fetch instead axios because it's native and with the knowledge acquired now it'll only just get better :)
I usually question fellow colleagues why we should use fetch, native or not, over other (well-tested) libraries like axios where these examples provided in this post are provided out-of-the-box, rather than re-defining the same fetch util checks ourselves.
Thanks George!
Fetch API is very powerful and now it's also available in Node.js.
Why are you checking
if (!response.ok) throw...again in the else block?Hey, If you’re talking about the last code snippet (example 2), this is the explanation: after checking if the error is 404 or 500, we need a way to check any other kind of failed response, which can be done by using ‘!response.ok’. So, if the server returns 400, for example, this code will throw an error as well. For 404 and 500, we display customized messages, that’s the reason we use ‘response.status’ for them.
Please, let me know if I answered your question, otherwise I’d like you provide me with more detail about which example you are talking about.
I see what you both mean!
Code snippet updated. Thanks a lot for the review.
Great post! Simple and informative. I feel like I’ve had both of these methods (try/catch and response checking) explained in various courses and tutorials but this is the first time I’ve seen it all put together and explained clearly (or maybe it’s just the first time it’s clicked for my brain).
Happy to hear that @cmgustin !! :)
It gets really interesting when you get the more unusual response codes like 3xx or 1xx. Should you trust the automated redirect or look at the location header yourself?
In case of 1xx -> should you poll for results? The fetch API supports all this, so the ball is firmly in your application logic’s court
This is an awesome post, Diona! Really nicely done. 🙌
Many thanks Michael!!! 🫶
Great article, thanks for posting
Thanks!!!!!
thanks for posting
You’re welcome! I hope you enjoyed it!! :)
Great post!
I was using the Optimal way (mentioned in the last) to handle errors but was not entirely sure why its the optimal way. Now I know. Thanks a lot!
You are very welcome!!
An ESLint rule for that would be nice 😃
That’s a nice idea!!!
Great post! The post make me learn more about fetch!
Very nice !
Nice! Need article about catch with AbortController :)
Great Post.
Thank you!!!
Absolutely! Handling errors in the Fetch API is crucial for robust web applications. I'd love to learn more about your insights on best practices in error handling!
Thanks for the suggestion!!! :)
Do you prefer using fetch or axios ? and how do you usually make fetch typesafe?
Hey @dsaga, of course axios provides some additional functionalities for handling HTTP requests, but most of the time I only need the native Fetch API.
I rather use fetch, creating my own wrapper to fit the project needs.
How about using Axios?
I would ask: why do you need to use Axios instead of the native Fetch API?
Might not spend time building something that's already built
may be not have time to get busy on json serialization
try {
const response = await fetch('restcountries.com/v4.1/all');
if (response.ok) {
console.log('Promise resolved and HTTP status is successful');
// ...do something with the response
} else {
// Custom message for failed HTTP codes
if (response.status === 404) throw new Error('404, Not found');
if (response.status === 500) throw new Error('500, internal server error');
// For any other server error
if (!response.ok) throw new Error(response.status);
}
}catch{
//This is executed when promises is not resolved.
}