使用co库和Promise相比使用thunk有哪些优点？

Question

我一直在阅读关于使用co库的文章，大多数博客文章中看到的通用设计模式是将具有回调函数的函数封装在thunk中。然后使用es6生成器将这些thunk yield到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);
  }
}

我可以理解这一点，因为它带来了诸如更好的可读性和更好的错误处理等承诺的所有好处。

但是，如果您已经可以使用承诺，那么使用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 使代码看起来更加混乱。

- m0meni

---

我还没有找到任何情况（忽略es7），在我看来使用生成器和承诺是有意义的。我看到的大多数例子只是为了使用生成器而使它更加复杂。 - Kevin B

CO 有其用途，但并不意味着你可以在任何地方使用它，即使它不合适！ - Jaromanda X

@KevinB 对于es7功能，您是指async/await还是其他功能？ - m0meni

关于异步/等待，它确实允许一些很酷的事情。 - Kevin B

Answer 1

实际案例是没有的，除非你真的讨厌 Promise 构造函数（在这种情况下，使用 bluebird 的 promisify 函数即可解决）。

当你本地拥有 Promise 时，几乎所有只被调用一次且带单个值回调的合法用例都将失去意义。

- Madara's Ghost

---

你对bluebird和native有什么看法？ - m0meni

对于服务器端，一路选择Bluebird。对于客户端，只有在您需要支持旧浏览器的Promise时才选择（否则，性能提升不值得您下载的字节数）。 - Madara's Ghost