前もって必要であることがわかっているすべての約束を作成します。それらを使用して構築.when
します。から返された promise を保存します.when
。新しい promiseを必要とする新しいイベントを追加するときは.when
、前.when
の からの promise と、完了した新しい promise を使用して、新しい を追加します。
「アプリを進めてください」としてsingle points of failure
ファイナルを使用している場合、アプリケーションには複数の があります。.when
IE: いずれかの promise が失敗した場合、その後に.when
作成されたものも失敗します。
...しかし、それがあなたの意図である場合、または確かなエラー処理がある場合は、それで十分です。
私はこのライブラリにとらわれないようにしようとしています -- 通常、私は独自の実装を使用します。これは、jQuery が行うことと、Crockford が最近の講演で行ったことの中間ですが、次のように仮定すると、
関数
は promise-handler を返す "when" が promise-handler を返す promise-handlers には少なくとも.done
and.fail
があり、または 2 つの引数を受け入れるか、関数内で何が起こるかによって、promise がrejected/resolved
or kept/broken
(または何でも) であるかどうかが制御されます。次のような一連の機能が得られる場合があります。
var doing = doSomething(), // returns promise
making = makeSomething(), // returns promise
loading = loadSomething(), // returns promise
dependencies_lvl_1 = when(doing, making, loading);
後で、新しいモジュールやウィジェットを追加するかもしれません -- 多分それはいくらかの手間を省きます:
var saving = saveSomething(), //returns promise
dependencies_lvl_2 = when(dependencies_lvl_1, saving);
その後、ページを切り替える必要があるかもしれませんが、最初にデータをキャッシュする必要があります
var caching = cacheData(), // returns promise
when(dependencies_lvl_2, caching)
.done(goToNextPage)
.fail(handleError);
それを見ると、すべての約束が守られている場合 (およびすべての約束が守られている場合) にのみ成功する約束を返す限り、それらのどれも壊れていないことがわかりますwhen
。追加のお約束。dependencies_lvl_2
dependencies_lvl_1
レベル 3.when
には、チェーンに追加されたすべてのものに応じた解決策があります。
そして、Promise を変数 (またはある種の将来アクセス) にキャッシュし続ける限り、これらを連鎖させ続けることができます。