みなさんこんにちは！

この記事では、deferred、 "deferred"（jQuery.Deferred）と呼ばれるバージョン1.5のjQueryライブラリが提供する非同期プロセス、および関連するオブジェクトとメソッドを実際にどのように使用できるかについて、いくつかの考えを共有したいと思います。。

もちろん、 deferred / promiseのペアを扱うというトピックについては、すでに12以上の記事が執筆されています。私の目標は、初心者に理解できない複雑さへの恐怖を忘れる機会を与え、次に非同期プロセスで動作する理解可能でよく構造化されたコードを書くための別の一歩を踏み出すような知識を提供することでした。私は、このオブジェクトを使用するための遅延、前提、および典型的なパターンを使用することで簡単に解決される問題に、あなたとあなたの注意を集中したいと思います。

非同期プロセス

そのため、非同期プロセスは、他のコードと並行して実行できると想定しており、その実行結果は、それを呼び出しているプログラムですぐに使用可能になりません。もちろん、これは奇妙です。同期アクションではなく、互いに並行して実行され、順次ではなく、次々に実行されますか？確立された用語を正当化するために：プロセスが「同期」であると言って、我々はその結果が現れる瞬間、すなわち 1つのプロセスの終了は、次のプロセスの実行の開始の瞬間と一致し、それらの終了と開始は同期されます。

var result = readValueBy(key); console.info(result);

「非同期」プロパティは、プロセスの結果が来ることを示していますが、これが発生するプログラム内の正確な場所を示すことは不可能です。非同期プロセスの結果を処理するロジックを記述するために、プログラマーはコールバック関数またはコールバック関数に頼って、実際の入力パラメーターの形式で作業の結果を渡します。

非同期プロセスの例

私たちは、ajaxリクエストが非同期プロセスになり得るという事実に慣れています。そして、jQueryの便利さを使用してサーバー呼び出しを作成するタスクに直面したとき、私たちは何も考えずに次のようなものを作成します。

 $.post("ajax/test.html", function( data ) { $( ".result" ).html( data ); });

さらに、これは$.post()

メソッドの公式jQueryドキュメントの例です（を参照）。

2番目のパラメーターはコールバック関数をメソッドに渡します。メソッドは結果を最初の引数（サーバーの応答）として受け取ります

そのようなリクエストの代替手段を次に示します。

 $.ajax({ type: "POST", url: "ajax/test.html", data: data, success: function( data ) { $( ".result" ).html( data ); }, dataType: dataType });

この例では、成功ハンドラーは、他のパラメーターと共にオブジェクトのsuccess

プロパティとして渡されます。

ただし、jQuery 1.5以降では、ハンドラーを渡さずにajaxメソッド（$ .get、$ .post、$ .ajax）を呼び出すことができます。これらのメソッドは、XMLHTTPRequestオブジェクトだけでなく、Promiseインターフェイスを実装するメソッドでオーバーロードされたこのオブジェクトを返します。実用的な観点から、これは非同期プロセス（=サーバーへのリクエスト）を開始することにより、実行の成功、エラー状況の処理などのために急いでコールバックを示すことができず、それらを指定する必要があるときに自分自身を制限しないことを意味します。サーバーリクエストを変数に保存できます：

 function api(key, data) { return $.post('ajax/' + key, data); } // .. var requestData = { id: '79001' }, storeDataRequest = api('get_store_by_id', requestData); //

...その後、必要なすべてのコールバックを「ハング」させます。

 function addStandardHandlers(request, requestData, model) { request.done(function(data){ //   ,        //        model.received(requestData, data && data.payload); }).fail(function(){ //      //   ,        model.received(requestData, null); }); } function addUIHandlers(request, $messageHolder) { //   .. request.done(function(data){ // ..   "", $messageHolder.text('Success'); }).fail(function(){ //    - // ",  " $messageHolder.text('Error, please retry.'); }).always(function(){ //   ,   ,   , //        window.setTimeout(function(){ $messageHolder.fadeOut(); }, 3000); }); } //  ,    addStandardHandlers(storeDataRequest, requestData, context.getModel()); //  ,   UI addUIHandlers(storeDataRequest, $('.main_page-message_holder'));

プログラムにサーバーに接続する必要がある場所が101箇所あり、どこでも応答構造が同じ処理を必要とする場合、サーバーのコールポイントでハンドラーに同じコードを生成せず、必要に応じてリクエストの各インスタンスを「ハング」させるAjaxリクエストが今や約束であることを知っています。以下の約束について参照してください。

その他の非同期プロセス

戻って、対処しなければならない他の非同期プロセスの例を挙げましょう。

1つ以上の画像をアップロードします（その後のサイズの設定、および画像の読み込みまたは失敗時に何らかの決定を行います）
ドキュメントの準備状態の発生（ dom readyイベント）
タイムアウト状態の開始
イテレータに実装された長い計算の完了とタイムアウトのゼロ
ページ要素のアニメーションの完了
ダイアログボックスの結果（「OK /キャンセル」）（たとえば、ダイアログボックスは、キャンセルボタン、上部の十字、さらにウィンドウの周囲の背景をクリックしても閉じることができますが、これはダイアログで提供される操作を達成していないと解釈できます）。
異種イベントの同時発生（たとえば、入力フォームのすべての条件への準拠、リストからすべての画像をダウンロードし、テンプレートを含むファイルをダウンロードする）、または予想されるイベントの少なくとも1つが発生する（タイムアウトが10秒の「リロード」ボタン）

遅延はどのような問題を解決しますか？

関数のパラメーターまたはオブジェクトのプロパティとしてコールバックを渡す以上のものが必要な状況について考えてみましょう（上記の簡単なajaxの例で見たように）：

同じプロセス終了イベントに複数のコールバックを割り当てる方法は？
完了後に予想されるイベントの発生を認識する方法は？
1つのプロセスで処理される状況のタイプごとにすべてのコールバックハンドラーをグループ化する方法

複数のonloadイベントハンドラーの最初のポイントの問題をどのくらい前に解決したかを覚えています。

 window.onload = (function(oldHandler){ return function(){ if (oldHandler) oldHandler(); // new code here.. }; })(window.onload);

これが過去の問題であることは良いことです。今日、ドキュメントイベントについて話している場合、これを行う人はいません（私は願っています）。そして約$ .Deferred（）-他のすべてについて話すとき。（意図的な誇張については申し訳ありませんが、ナレーションの目的を果たします。）さて、「複数のハンドラーで何をすべきか？」は別の質問です。たとえば、一方がデータを解析でき、もう一方が-上記の例で提案したように、雇用指標を非表示にするか、ステータステキストを変更するとします。以前は、モデルとディスプレイの両方を1つのハンドラーに押し込む必要がありましたが、今では共有の自由があります。

また、数年前、 2番目のポイントは、ハンドラーの本体が閉じられているフラグ変数の周りに何らかの種類の積み上げをすることによって解決されました。ウィジェットがロードされるまでにすでにdom readyが実行されていることをウィジェットに伝える方法についてどのように考えたかをはっきりと覚えています。しかし、 $(function(){ ... })

がありましたが、これは遅延を使用してjQueryに実装されています。これは、 dom readyイベントが発生した後にコードが実行された場合でも、この設計のコールバックが機能することを意味します。使用パターンは簡単です。ハンドラーを「ハングアップ」します。プロセスが既に完了している場合、ハンドラーはすぐに実行されます。そうでない場合、ハンドラー（このタイプのすべてのハンドラー）は、将来の発生時に実行されます。

3番目の問題を解決するために延期してみましょう。延期では、プロセスを正常に完了するためのハンドラーのグループがあります。失敗（誤ったまたは予期しない）終了の場合、 任意の終わりに呼び出されるグループ（「愛」）があります。ハンドラーが操作の進行状況を追跡できるグループもあります。

そこで、$ .Deferred（）を使用して解決される3つの問題を調べました。

遅延を使用するための前提条件

プログラムで遅延を使用することを検討する必要がある場合の条件の概要を説明します。

その後、Deferredの使用について考えます。

状態の開始を待機し、その開始および/または関連データのインジケータを保存する必要がある場合。条件の発生を待つことが最初の条件です。
2番目の条件は、長いプロセスのコードの相対的な配置と、その変更/完了を処理するコードについて考えるときです。 Deferredを使用すると、受信方法と後続処理の方法を決定することで、データ/結果を取得する方法の定義を「アンティ」できます。

最初の条件の特徴は、条件が発生した瞬間だけではなく、条件の開始であることに注意してください。これにより、jQueryの通常のイベント処理メカニズムとDeferredが区別されます。イベントが発生し、ハンドラと呼ばれ、忘れられました。設定したDeferredによって決定されたプロセスの状態は、Deferredを格納している限り持続します。

2番目の前提。コードを見てみましょう。

 $.post("ajax/cart", function( data1 ) { //  1. //   data1 // if (data1 && data.success) .... //  2. //      var processedData1 = data1.payload; //  3. //      : $.post("ajax/shipping", processedData1, function( data2 ) { //  1. //  2. var processedData2 = data2.payload; //  3. $.post("ajax/payment", data2, function( data3 ) { //  1. //  2. var processedData3 = data3.payload; //  3.    $( ".result" ).html( processedData3 ); }); }); });

最初の要求はデータを受け取り、それに基づいて2番目の要求が行われ、その結果に基づいて-後続の要求などが行われます。リクエストは3つだけで、ロジックは示されているだけで、よく知られているアンチパターン「運命のピラミッド」（運命のピラミッド）が既にあります。

私がたまたま参加したプロジェクトの1つで、タスクは密かに動作する支払いシステムサイトを「ラップ」することでした（CGIで記述されており、サポートされていなかったため、スタイリング、変更、サイトへの埋め込みの問題はありませんでした）-美しいページWordPressで「日陰で」、非同期の取得およびポストリクエストを使用して、ユーザーアクションをエミュレートします（カートページの入力、商品の再集計、フォームの送信、送信の確認ページの受信、アドレスの入力、2番目のフォームの送信、支払いデータの入力..）私は知っている、知っている。これは悪いです。詳細を覚えているのは恥ずかしいです。かつて、私はそこに行ってリファクタリングすることを恐れていました。「うまくいきました。」しかし、最悪の事態は、支払いロジックを含む方法が6レベルまたは7レベルのネストを持ち、画面の高さを10倍にしたことです。この決定により、この方法のみをサポートするか、CGIをゼロからマスターするかの選択は明白ではなくなり、CGIがわずかに有利になりました。今、そのような決定で何をしますか（購入のシーケンスを模倣することは「OK」であるふりをしましょう）。

最初に、メソッドのロジックをステップに分割します。上記の例に基づいて説明します。

 function purchaseStep01_CartDataRequestFor(input) { return $.post("ajax/cart", input); } function purchaseStep02_UpdateShippingInfoRequestFor(input) { return $.post("ajax/shipping", input); } function purchaseStep03_SubmitPaymentDetailsRequestFor(input) { return $.post("ajax/payment", input); }

第二に、リクエストを送信するだけでは不十分です。回答を解析するための一般的な機能として提供する必要があります。

 //   : // -  -  -  //   /   function handleResponseData(request, specificLogic) { //    -promise,    fail //   ,  AJAX  ,   //        success==true // (          ) //      ,      return $.Deferred(function(def){ request .fail(def.reject) .done(function(data){ if (!data || !data.success) return def.reject(); if (!specificLogic) return def.resolve(data); try { def.resolve(specificLogic(data)); } catch (e) { def.reject(e); } }); }).promise(); }

...および各リクエストの結果を個別に処理するためのロジック。上記を使用してこのロジックと互換性があります。

 //  1.   .  . var step01_CartDataPromise = handleResponseData( purchaseStep01_CartDataRequestFor(data), function (data){ //       . //    -  ,    fail. if (!data.cart) throw new Error('Cart info is missing'); //  -  ,     cartInfo  . return data.cart; }), // <- , ..         . //  2.       1. //       : // step02_ShipInfoPromise = step01_CartDataPromise.then().done(function(cartInfo){... // then()   ,      // .      jQuery step02_ShipInfoPromise = step01_CartDataPromise.then(function(cartInfo){ return handleResponseData( purchaseStep02_UpdateShippingInfoRequestFor({ id: cartInfo.id}), function (data){ if (!data.shipping) throw new Error('Shipping info is missing'); return { cart: cartInfo, shipping: data.shipping }; }); }), //  3.     2. step03_PaymentResultPromise = step02_ShipInfoPromise.then(function(prePurchaseInfo){ return handleResponseData( purchaseStep03_SubmitPaymentDetailsRequestFor(prePurchaseInfo), function (data){ if (!data.payment) throw new Error('Payment gone wrong'); return data.payment; }); }); // <-    //          ,  //       //     done()  then()  function(paymentInfo)..  //    function(prePurchaseInfo)..   . // .    2. step03_PaymentResultPromise.then(function(paymentInfo){ $('.result').html( paymentInfo.message ); });

この決定の短所：

ロジック関数のフレーミングにより、コードはより多くの行に書き込まれます
$.Deferred(..)

コンストラクターがどのように機能するかを覚えておく必要があり$.Deferred(..)

また、2つのプロミスを次から次へとリンクする方法$.Deferred(..)

を覚えて、その中にプロミスを与えることを忘れないでください。つまり promiseを返すhandleResponseData

関数を呼び出す前にreturn

忘れないでください。

長所：

データを送信するロジックと受信した応答を処理するロジックの多様性
ある場所での操作の成功と、外部からこの決定に影響を与えられないことに関する意思決定のロジックの場所。 handleResponseData()

メソッドの$.Deferred(..).promise()

の束。
異なる段階での同じ操作の成功に関する決定ロジックの場所。 handleResponseData()

内のdef.reject(..)

呼び出しに注意してdef.reject(..)

。サーバーが動作を拒否した場合だけでなく、正常に動作したが不十分なデータが返された場合も、操作は失敗したと見なされます。また、データが処理後に検証に合格しなかった場合（ catch(e){ .. }

ブランチ）。次に、$ .Deferredを使用せずに実装する方法を考えます。
ロジックの構造化の改善、ネストの削減、サポート性の向上。

数と質の両方を上回る利点があると主張する人はほとんどいません。

前提を実証したようです。さらに進みましょう。例を始める前に、約束についていくつかの言葉を約束します。

約束

遅延オブジェクトへのリンクがあるため、プログラムはプロセスの結果（プロセス自体ではなく、場合によってはそうである）を制御し、すべてのリスナーに結果を「伝える」機能を備えています。ただし、この遅延オブジェクトに関連付けられているpromiseオブジェクト、または「promise」は、プログラムに「リスニング」専用のメソッドセットを提供します。（このトピックに関するウィキペディアの記事では、このような読み取り専用オブジェクトはfutures（future）と呼ばれ、$ .DeferredはjQueryとして機能します。混乱しないようにしてください。）実際、この権限の分離により、コードは「想定されていない」ことをしたいのです。

 var def = $.Deferred(); //   , //  "" def.resolve()  def.reject() // //  readonly- promise, //   def //  ""  var promise = def.promise()

ほとんどの場合、遅延参照を使用する最も便利で安全な方法は、作成時にパラメーターによって渡される関数内でロジックを定義することです。

 $.Deferred(function(def){ //       , //  resolve()  reject() //    . });

そのような使用は、 .promise()

呼び出すことにより、このオブジェクトへのアクセスをブロックするために、すぐに（忘れずに）「戻る」ことができます。

簡単な例。タイムアウトの開始は、プロセスの正常な完了を決定します。

 function doneTimeout(timeout) { return $.Deferred(function(def){ window.setTimeout(def.resolve, timeout); }).promise(); }

約束について話す約束を果たしたようです。例。

例

しばらく前に、延期/約束の概念を考えることが完全にできなかったと言います。

写真をアップロードする

特に、そこで写真の読み込みを制御する手順について知りました。しかし、写真がロードされたかどうかだけでなく、そのサイズも認識できるように、それを追加するようになりました：

 var loadImage = createCache(function(defer, url) { var image = new Image(); function cleanUp() { image.onload = image.onerror = null; } defer.then( cleanUp, cleanUp ); image.onload = function() { defer.resolve( url, { width: image.width, height: image.height }); }; image.onerror = defer.reject; image.src = url; });

ドキュメントの準備完了状態の発生の判定

すでに$(function(){.. })

。ドキュメントの準備が整ったという約束のオブジェクトを純粋な形で取得する方法を教えてください。

 var domReadyPromise = $.ready.promise();

タイムアウトステータスの開始

タイムアウトの例については既に検討しました。タイムアウトの発生には、プロセスの正常な完了が必要であるdoneTimeout()

ます。しかし、タイムアウトによってプロセスがエラーで完了したと見なされるオプションも必要になりました。ここにあります：

 function failTimeout(timeout) { return $.Deferred(function(def){ window.setTimeout(def.reject, timeout); }).promise(); }

10秒後に自動的に押すため、ボタンを押すかどうかを気にしないボタンのロジックを実装できます。これは起こりますか？誰がこれを考えることができますか？

 var timeToSubmit = $.Deferred(function(def){ doneTimeout(10000).done(def.resolve); $('.submissionButton').one('click', function(){ def.resolve(); return false; }); }).promise(); timeToSubmit.done(function(){ //       //    });

ページ要素のアニメーションを終了する

サーバーからデータが到着した時点ではなく、ポップアップメッセージでそれらを慎重に表示してからこのメッセージを消すときに、プロセスが完了することを考慮する必要がある場合があります。もちろん、次のようにバンドルを作成できます（これは、ノートの最後にあるリンクの1つを使用した修正された例です）。

 function animationPromise($element){ return $.Deferred(function(def){ $element.fadeIn( 10000 , def.resolve ); }).promise(); }

ただし、これは完全に不要です。各jQuery要素はpromise（）呼び出しをサポートし、アニメーションを終了するpromiseを返します：

 function animationPromise($element){ return $element.fadeIn( 10000 ).promise(); }

次のように、アニメーションの最後まで「聞く」ことができます。

 animationPromise($('#foo')).done(function(){ console.log('Animation is finished'); });

または単に：

 $element.fadeIn( 10000 ).promise().done(function(){ console.log('Animation is finished'); });

この方法で、あるアニメーションを別のアニメーションに「紐付け」しないことを忘れないでください。これには、より簡潔で定期的な方法があります。

 $element.fadeIn( 10000 ).fadeOut( 10000 );

モーダルダイアログの維持

ページインターフェイスとのユーザーインタラクションを改善するライブラリの例は数多くありますが、プログラマーのことを忘れることがあります。

例は、Twitter Bootstrapのモーダルウィンドウの実装です（こちらを参照）。「表示」と「非表示」、「ウィンドウが開いている」、「ウィンドウが隠れている」というイベントがあります。しかし、プログラマーは、このウィンドウでユーザーがどのような選択をしたかをどのようにして見つけることができますか？つまりどのリンクやボタンを使用したのではなく、アクションで何を言ったのでしょうか？彼の選択は、計画されたプロセスの正常な完了またはキャンセルにつながりましたか？たとえば、ダイアログボックスは、キャンセルボタンで閉じることができ、上部に十字があり、ウィンドウの周囲の背景をクリックすることもできますが、これはダイアログで提供される操作を達成していないと解釈できます。

もちろん、このトピックが彼に近い場合は、読者にTwitter Bootstrapモーダルウィンドウラッパーの独自の実装について考えることをお勧めします。そして、私自身の例を別の機会に挙げましょう。

複数のプロセスの期待を組み合わせる

複数の保留中のプロセスの期待を組み合わせる必要があることは明らかです。上記では、タイムアウトまたはボタンを押すという2つの状態のいずれかの迅速な開始を待つ例を検討しました。いくつかのイベントが発生すること自体がイベントになり、その結果がそのコンポーネントの結果に依存する、多くの同様の状況があります。

人材派遣jQueryの申し出たちを法$.when()

受け入れる約束をし、新しい与え約束各彼の約束のコンポーネント、および故障が正常に完了したことを完成することになっている成功うちに、 -いずれかの少なくとも一方の故障。これは一種の論理演算Iです。すべてのオペランドがTRUEである場合にのみ出力がTRUE（=成功）になり、それ以外の場合はFALSE（=失敗）になります。

見てのとおり、論理ORの類似物では不十分です。つまり約束を組み合わせたこのような方法は、すべての約束が失敗した場合にのみ、操作の失敗を通知します。また、他の場合、操作は正常に終了します。

ここで、このような実装の独自のスケッチを示します。

 // fail if and only if all fail: function failIifAllFail(_promise_array){ var promises = [].slice.apply(arguments), count = promises.length; return $.Deferred(function(def){ //      var done = 0, fail = 0; //             //   check() ,       //     $.each(promises, function wrap(key, p){ p.done(function(){ done++; check(); }).fail(function(){ fail++; check(); }); }); function check(){ if ((done + fail) < count) return; if (fail === count) def.resolve(); else def.reject(); } }).promise(); }

長期実行コンピューティング制御

継続的なコンピューティング-出くわす人は確認する-特別なアプローチが必要です。計算反復子が呼び出されるサイクル。裏返し、反復子を無効にし、タイムアウトを使用して、しばらく実行を呼び出し、結果が得られるまで呼び出しを繰り返します。プロセスが正確にいつ終了するかは、すぐにはわかりません。約束を適用する可能性があります。

読者が実装について自分で考え、次に何が起こるかを別のメモで比較することをお勧めします。

ご清聴ありがとうございました！

非同期タスクの操作での$ .Deferredの使用について