使用带有 promise 而不是 thunk 的 co 库有什么好处？答案

【问题标题】：What are the benefits of using the co library with promises instead of with thunks?使用带有 promise 而不是 thunk 的 co 库有什么好处？
【发布时间】：2016-04-09 21:09:04
【问题描述】：

所以我一直在阅读有关 co 库的用法的信息，并且我在大多数博客文章中看到的一般设计模式是包装在 thunk 中具有回调的函数。然后使用 es6 生成器将这些 thunk 生成到 co 对象。像这样：

co(function *(){
  var a = yield read(‘Readme.md’);
  var b = yield read(‘package.json’);
  console.log(a);
  console.log(b);
});
function read(path) {
  return function(done){
    fs.readFile(path, ‘utf8', done);
  }
}

我可以理解，因为它带来了 Promise 的所有好处，例如更好的可读性和更好的错误处理。

但是，如果您已经有可用的承诺，那么使用 co 有什么意义呢？

co(function* () {
  var res = yield [
    Promise.resolve(1),
    Promise.resolve(2),
    Promise.resolve(3),
  ];
  console.log(res); // => [1, 2, 3]
}).catch(onerror);

为什么不喜欢

Promise.all([
  Promise.resolve(1),
  Promise.resolve(2),
  Promise.resolve(3),
]).then((res) => console.log(res)); // => [1, 2, 3]
}).catch(onerror);

对我来说，与 Promise 版本相比，co 使代码看起来更加混乱。

【问题讨论】：

我没有发现任何情况下（忽略 es7）对我来说使用带有 Promise 的生成器是有意义的。我见过的大多数例子只是让它变得更复杂，以便他们可以使用生成器。
co 有它的用处，不代表你到处用它，即使它不合适！
@KevinB 对于 es7 功能，您指的是 async/await 还是其他？
指的是异步/等待，它确实允许一些很酷的东西。

标签： javascript node.js promise async-await thunk

【解决方案1】：

没有真实案例，没有。除非你真的讨厌 promise 构造函数（在这种情况下，bluebird promisify 来救援）。

当您拥有原生 Promise 时，几乎所有使用单个值调用一次的有效回调用例实际上都没有实际意义。

【讨论】：

你对蓝鸟和原生有什么看法？
服务器端，bluebird一路。对于客户端，仅当您希望在旧版浏览器中支持 Promise 时（否则，性能提升不值得您下载所需的字节数）