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

所以我一直在阅读co库的用法,我在大多数博客文章中看到的一般设计模式是包含回调函数的函数.然后使用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);
  }
}

而且我可以理解,因为它带来了承诺的所有好处,例如更好的可读性和更好的错误处理.

但是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使代码看起来更加混乱.

没有真实案例,没有.除非你真的讨厌承诺构造函数(在这种情况下,蓝鸟promisify来救援).

当你本机拥有Promise时,几乎所有用于使用单个值调用一次的回调的有效用例实际上没有实际意义.