将 fetch 包装在 Promise 中有什么好处？ [复制]答案

【问题标题】：What is the benefit of wrapping fetch in a promise? [duplicate]将 fetch 包装在 Promise 中有什么好处？ [复制]
【发布时间】：2019-10-12 13:59:43
【问题描述】：

我看到人们将 fetch 方法包装在一个 Promise 中。我似乎无法理解这样做的好处？ Fetch 本身会返回一个 Promise，您可以从中提取您需要的内容。

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);
 })

与此相比

return new Promise((resolve, reject) => {
  fetch(url)
  .then(res => res.json())
  .then(data => resolve(data))
  .catch(err => reject(err));
});

【问题讨论】：

收益为零。这是人们在使用 Promise 时常犯的错误。（如果Promise不是指原生promise，正确的包装方式还是Promise.resolve，而不是构造函数。）

标签： javascript promise fetch-api

【解决方案1】：

其实是有道理的。我会给你三个例子，在这些例子中这个场景非常有用。

假设我们有很多地方都在调用 distance rest api。可能有数百页甚至更多。现在，我们需要将 custom header 插入到我们发送的每个请求中。嗯...如果我们有我们的包装器，从许多地方调用，然后从我们的包装器中提取一个，那么我们可以简单地在我们的包装器中添加新的标头，所有调用都将包含新的标头。
我们重构了代码，现在我们有了新的、闪亮的 fetch 包装器。我们插入了自定义标题，一切正常。但是一段时间后，我们发现可以说 axios 是比使用 fetch 更好的库。幸运的是（哈哈！）我们包装了 fetch，现在只有一个重构的地方。如果我们不这样做，我们将需要经过数百甚至更多的地方来改变......现在，我们甚至可以不只是改变它，而是实现类似“策略模式”的东西，我们可以在其中使用一个或另一个（fetch 或 axios），我们可以动态切换。
因为我们封装了这些实现，所以我们控制了我们在代码中进一步使用的接口。如果某些包装的第三个库更改，例如。它的属性名称，我们将仅在我们的包装器中修复它。我们应用程序的其余部分正在使用我们保持不变的界面。

快速回顾一下，当你包装它时，你现在只有一个地方可以改变，如果需要改变，将来你可以切换多个实现。这是一个很好的做法，尤其是在使用 3rd 方库时，包装它们或制作适配器。

希望这会有所帮助。

【讨论】：

您正在回答问题“将fetch 包装在函数中有什么好处？”。这不是被问到的。
你说得对，我没抓住重点。

【解决方案2】：

“无论成功与否，它都会返回一个解析为该请求的响应的 Promise。”

Source

没有意义。这只是人们正在做的事情，他们可能习惯于使用 jQuery Deferreds 之类的东西，这些东西没有适当的 A+ Promise 实现。如果你愿意，如果你使用像 Bluebird 这样的东西我猜你可以这样做，但它或多或少毫无意义。

【讨论】：