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...
Some comments have been hidden by the post's author - find out more
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.
Always curious why send to browser 25 kb minified library, which does practically nothing. While we can use native code, which is doing the same, and cost nothing.
Thanks George!
Fetch API is very powerful and now it's also available in Node.js.
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 !! :)
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.
This is an awesome post, Diona! Really nicely done. 🙌
Many thanks Michael!!! 🫶
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
Great article, thanks for posting
Thanks!!!!!
An ESLint rule for that would be nice 😃
That’s a nice idea!!!
Great post! The post make me learn more about fetch!
Nice! Need article about catch with AbortController :)
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!!
Very nice !
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!!! :)
Great Post.
Thank you!!!
Great article, thanks for posting
Thank you!
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.
Minor: should capitalize the
iin the messageiniternal server errorHow 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
check here advanced way to handle fetch error in react app : github.com/idurar/idurar-erp-crm/b...
IDURAR is open source erp crm based on mern-stack Node.js React.js MongoDB ANT Design : github.com/idurar/idurar-erp-crm
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.
}
Great post, very clear, nice to not need to use Axios anymore, a little util to wrap up this combination of try / catch with fetch and it looks good !
I need this. This is refreshing. I answered yes to your initial question. So I really need a review. Thank you.
Hmm, i always procrastiated about error handling and its incredible that you teached it so great. Doing something is hard, teaching is impossible