3 ms·

Also it has interceptors, which allow you to build easily reusable pieces of code - loggers, oauth, retriers, execution time trackers etc. These are so much be

by seer 6mo ago

Also it has interceptors, which allow you to build easily reusable pieces of code - loggers, oauth, retriers, execution time trackers etc. These are so much better than the interface fetch offers you, unfortunately.

reactordev 6mo ago
You can do all of that in fetch really easily with the init object. fetch('https://api.example.com/data', { headers: { 'Authorization': 'Bearer ' + accessToken } })
- mhio 6mo ago
  What does an interceptor in the RequestInit look like?
  - reactordev 6mo ago
    A wrapper function around fetch… that’s what interceptors are…
- zdragnar 6mo ago
  There are pretty much two usage patterns that come up all the time: 1- automatically add bearer tokens to requests rather than manually specifying them every single time 2- automatically dispatch some event or function when a 401 response is returned to clear the stale user session and return them to a login page. There's no reason to repeat this logic in every single place you make an API call. Likewise, every response I get is JSON. There's no reason to manually unwrap the response into JSON every time. Finally, there's some nice mocking utilities for axios for unit testing different responses and error codes. You're either going to copy/paste code everywhere, or you will write your own helper functions and never touch fetch directly. Axios... just works. No need to reinvent anything, and there's a ton of other handy features the GP mentioned as well you may or may not find yourself needing.
  - anon7000 6mo ago
    Helper functions seem trivial and not like you’re reimplementing much.
    - creshal 6mo ago
      Don't be silly, this is the JS ecosystem. Why use your brain for a minute and come up with a 50 byte helper function, if you can instead import a library with 3912726 dependencies and let the compiler spend 90 seconds on every build to tree shake 3912723 out again and give you a highly optimized bundle that's only 3 megabytes small?
  - sayamqazi 6mo ago
    > usage patterns IMO interceptors are bad. they hide what might get transformed with the API call at the place it is being used. > Likewise, every response I get is JSON. There's no reason to manually unwrap the response into JSON every time. This is not true unless you are not interfacing with your own backends. even then why not just make a helper that unwraps as json by default but can be passed an arg to parse as something else
  - arghwhat 6mo ago
    Interceptors are just wrappers in disguise. const myfetch = async (req, options) => { let options = options || {}; options.headers = options.headers || {}; options.headers['Authorization'] = token; let res = await fetch(new Request(req, options)); if (res.status == 401) { // do your thing throw new Error("oh no"); } return res; } Convenience is a thing, but it doesn't require a massive library.
    - deleted 6mo ago
      [deleted]
    - pixel_popping 6mo ago
      but it does for massive DDoS :p
    - 6mo ago
meekins 6mo ago
It also supports proxies which is important to some corporate back-end scenarios
- nathanmills 6mo ago
  fetch supports proxies

by seer 6mo ago

reactordev 6mo ago

You can do all of that in fetch really easily with the init object. fetch('https://api.example.com/data', { headers: { 'Authorization': 'Bearer ' + accessToken } })

mhio 6mo ago
What does an interceptor in the RequestInit look like?
- reactordev 6mo ago
  A wrapper function around fetch… that’s what interceptors are…
zdragnar 6mo ago
There are pretty much two usage patterns that come up all the time: 1- automatically add bearer tokens to requests rather than manually specifying them every single time 2- automatically dispatch some event or function when a 401 response is returned to clear the stale user session and return them to a login page. There's no reason to repeat this logic in every single place you make an API call. Likewise, every response I get is JSON. There's no reason to manually unwrap the response into JSON every time. Finally, there's some nice mocking utilities for axios for unit testing different responses and error codes. You're either going to copy/paste code everywhere, or you will write your own helper functions and never touch fetch directly. Axios... just works. No need to reinvent anything, and there's a ton of other handy features the GP mentioned as well you may or may not find yourself needing.
- anon7000 6mo ago
  Helper functions seem trivial and not like you’re reimplementing much.
  - creshal 6mo ago
    Don't be silly, this is the JS ecosystem. Why use your brain for a minute and come up with a 50 byte helper function, if you can instead import a library with 3912726 dependencies and let the compiler spend 90 seconds on every build to tree shake 3912723 out again and give you a highly optimized bundle that's only 3 megabytes small?
- sayamqazi 6mo ago
  > usage patterns IMO interceptors are bad. they hide what might get transformed with the API call at the place it is being used. > Likewise, every response I get is JSON. There's no reason to manually unwrap the response into JSON every time. This is not true unless you are not interfacing with your own backends. even then why not just make a helper that unwraps as json by default but can be passed an arg to parse as something else
- arghwhat 6mo ago
  Interceptors are just wrappers in disguise. const myfetch = async (req, options) => { let options = options || {}; options.headers = options.headers || {}; options.headers['Authorization'] = token; let res = await fetch(new Request(req, options)); if (res.status == 401) { // do your thing throw new Error("oh no"); } return res; } Convenience is a thing, but it doesn't require a massive library.
  - deleted 6mo ago
    [deleted]
  - pixel_popping 6mo ago
    but it does for massive DDoS :p
  - 6mo ago

meekins 6mo ago

It also supports proxies which is important to some corporate back-end scenarios

nathanmills 6mo ago
fetch supports proxies