web-dev-qa-db-ja.com

それらを使用する関数からpromiseを返す必要がありますか？

Promisesは私にとってかなり新しいパターンなので、私はまだ彼らのために直感を構築しています。

最近、アダプターのようなコードの一部のコードがかつて同期していて、その後非同期になったというケースに遭遇したため、promiseが導入されました。考えてみましょう：

function runCalculation() {
  var params = this.getParams();
  this.callLibraryCalculation(params);
}

ここで、getParamsはさまざまな場所から値を収集し、それらをcallLibraryCalculationで使用できる1つのオブジェクトに配置します。これにより、予想どおり、外部ソースからの呼び出しがラップされます。これはすべて、質問の目的のために明らかに単純化されています。

したがって、新しいユースケースが必要になるまで、これはすべて機能しましたgetParams外部APIから値の一部を取得し、非同期動作を導入しました。そのため、その関数は、promiseを使用して返す非同期を処理するように変更されました。それはそれを消費することが変わったことを意味します。

function runCalculation() {
  return this.getParams().then(function(params) {
    this.callLibraryCalculation(params);
  });
}

runCalculationを呼び出す関数には、。then（）-edが必要な依存ロジックがあるため、ここでpromiseを返すことにしました。しかし、私の質問はrunCalculationの呼び出し元についてです。彼らは今、ここに戻ってきたものを消費した結果として、彼ら自身の約束を生み出しています。呼び出し元は実行の終了を表すため、現在、これらの約束のほとんどをエーテルに逃がすことができます。しかし、実行が終了していない場合、この約束の受け渡しが大量のコードに侵入し始め、呼び出し元から呼び出し元にバブリングすることに気付きました。

私の傾向は、ロジックを順序付けるために1つを使用する必要がある関数から常にpromiseを返すことです。

その傾向は良い直感ですか？ Promisesが導入されると、コードが引き継がれるのではないかと心配する必要がありますか？

または、より答えやすい質問をするために：そのような慣行に賛成または反対することを私が見逃したかもしれない考慮事項はありますか？

javascriptpromises
4
TwainJ

私の傾向は、ロジックを順序付けるために1つを使用する必要がある関数から常にpromiseを返すことです。

非同期操作を伴う関数があり、promiseを使用していて、関数の呼び出し元が非同期操作がいつ実行されたか、またはその最終値が何であるかを知りたいと思う理由がある場合は、必ず、あなたがすでに内部に持っていることを約束します。

これにより、発信者の柔軟性が高まります。呼び出し元が返されたpromiseを使用しないことを選択した場合、それは問題ありません。少なくとも、発信者がそれを使用したい場合はそこにあります。

Promisesが導入されると、コードが引き継がれるのではないかと心配する必要がありますか？

「コードを引き継ぐ」とはどういう意味かわかりません。呼び出し元に非同期完了へのアクセスを許可する場合は、promiseを返します。発信者に非同期完了へのアクセスを許可したくない場合は、promiseを返さないでください。それ以上に複雑ではありません。

関数内の非同期操作は、含まれている関数を非同期にします。その点で伝染性です。また、promiseは、非同期結果を提供し、複数の非同期操作を調整するための最良の方法です。したがって、非同期操作を使用するすべてのコードは、promiseを使用する必要があります。これは「コードを引き継ぐ」ことではありません。非同期コードを設計するためのインテリジェントな方法です。今あなたにとって不自然に思えるなら、あなたはそれをするためのより多くの経験と練習が必要です、そしてそれは自然で簡単になり始めます。その時点では、コードが何かに乗っ取られたようには感じられませんが、その仕事に適したツールを使用しているように感じます。

5
jfriend00