7

私はcoライブラリの使用法について読んでいましたが、ほとんどのブログ投稿で見た一般的な設計パターンは、サンクでコールバックを持つ関数をラップすることです。次に、es6 ジェネレーターを使用して、これらのサンクを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);

私にとって、co は Promise バージョンと比較してコードをより混乱させます。

4

1 に答える 1

8

実際のケースはありません。promise コンストラクターが本当に嫌いでない限り (その場合、ブルーバードpromisifyが助けになります)。

Promise がネイティブにある場合、単一の値で 1 回呼び出されるコールバックのほとんどすべての有効なユースケースは事実上意味がありません。

于 2016-01-05T22:02:08.280 に答える