5

I see people wrapping the fetch method in a promise. I can't seem to understand the benefit of doing so? Fetch itself returns a promise and you can extract what you need from that.

let url = 'https://jsonplaceholder.typicode.com/users';

fetch(url)
 .then(function(response){
   //console.log(response.json());
   return response.json();

 })

 .then(function(data){
   console.log(JSON.stringify(data));
 })

 .catch(function(err){
 //console.log(err);
 err = 'this is an error';
 console.log(err);
 })

compared to this

return new Promise((resolve, reject) => {
  fetch(url)
  .then(res => res.json())
  .then(data => resolve(data))
  .catch(err => reject(err));
});
larry burns
  • 189
  • 1
  • 9
  • There’s zero benefit. That’s a common mistake people make when using promises. (If `Promise` doesn’t refer to the native promise, the right way to wrap it is still `Promise.resolve`, not the constructor.) – Ry- May 27 '19 at 00:59

2 Answers2

2

"It returns a Promise that resolves to the Response to that request, whether it is successful or not."

Source

There is no point. It's just something people are doing who are probably used to working with things like jQuery Deferreds which don't have a proper A+ Promise implementation. If you wanted, you could do this if you were using something like Bluebird I guess but it's more or less pointless.

Roamer-1888
  • 19,138
  • 5
  • 33
  • 44
Vaughan Hilts
  • 2,839
  • 1
  • 20
  • 39
1

Actually there is point. I will give you three examples where this scenarios is very useful.

  1. Lets say that we have many places in which we are calling distance rest api. Maybe hundred of pages or even more. And now, we have the need to insert custom header into every request we send. Hm... If we had our wrapper, called from many places, and then one fetch from our wrapper, then we can simply add new header inside our wrapper and all calls will contain new header.

  2. We refactored our code, and now we have our new and shiny wrapper around fetch. We inserted our custom header and everything works fine. But after some time, we found that lets say axios is much better library then using fetch. Fortunately ( a ha! ) we wrapped fetch and now have just single place to refactor. If we didn't, we would need to go over hundered or even more places to change.... Now, we have possibility to not even just change it, but implement something like "Strategy pattern", where we can use one or another (fetch or axios), which we can dynamically switch.

  3. Because we wrap these implementations, we control our interface we use further in our code. If some wrapped third library change, for eg. its property name, we will fix that only in our wrapper. The rest of our application is using our interface which stays unchanged.

Quick recap, when you wrap it, you now have only one place to change, if need for that change appear, also, you can switch multiple implementations in the future. Its a good practice, especially when working with 3rd party libs, to wrap them or made adapters.

Hope this helps.

Aleksandar Stojilkovic
  • 367
  • 2
  • 8