JavaScriptで非同期性と友情を築いた方法

JavaScriptはほとんど戸口から非同期で開発者に会います。 すべては、DOMイベント、ajax、タイマー、およびアニメーションに関連するライブラリメソッド（たとえば、jQueryメソッドfadeIn / fadeOut、slideUp / slideDown）で始まります。 一般に、これはそれほど難しくなく、この段階で非同期に対処することは問題ではありません。 ただし、上記のすべてを組み合わせた、多少複雑なアプリケーションの記述に移るとすぐに、非同期ストリームはコードで何が起こっているのかを理解するのを非常に複雑にする可能性があります。 アニメーション> ajax-request>初期化->アニメーションなどの非同期アクションのチェーンは、「下から上へ」という厳密な方向に従わない、かなり複雑なアーキテクチャを作成します。 この記事では、非同期JSに関連する困難を克服した経験についてお話します。



最初、私にとってJavaScriptの最も素晴らしい瞬間の1つは次のとおりでした。

for(var i=0; i<3; i++){ setTimeout(function(){ console.log(i); }, 0); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

見るのはすごかった：

 3 3 3
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

予想される代わりに：

 0 1 2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

退屈なエントリ



そのため、非同期は、「おおよそ」それが期待される場合（たとえば0ミリ秒）、および「同期」ストリーム（ブロック）の実行が終了するとき、つまり「できるだけ早く」実行されるものとして認識される必要がないことに気付きました「。 実生活ではほとんどすべてのプロセスが非同期であるため、わかりやすい類推をするのは簡単ではありません。 あなたが建設会社のマネージャーだと想像してください。 ターンキーハウスの建設注文を受け取りましたが、このサイトでの特定の種類の作業（たとえば、家の建設）の許可を得ているのはサードパーティ企業のみであり、それらに連絡する必要があります。 すでに確立されたアルゴリズムがあります：基礎を埋め、家を建て、家を塗り、陰謀を立てるなど、しかし、私たちのケースでは、家を建てず、いつ建てられるかさえ知りません。 これは非同期プロセスであり、タスクは単にレイアウトを会社に転送し、完成した建物を取得することです。 家を建てるときは、すべてがシンプルであり、建設、塗装などの現在のプロセスに注意を集中します。 しかし、今は家を建てていません。 どういうわけか、状況を考慮して、チームの作業を整理する必要があります。 これは、非同期プロセスの間、実行スレッドをブロックする必要がない理由を最もよく説明します-スレッドはアイドル状態です。 実行のスレッドがブロックされていない場合、非同期アクションが発生している間、他のことを行うことができます。



JavaScriptに関して最も人気のある初心者のバグは、次のようになります。

 function Build(layout){ //...         //...   ,   JS  (  house) } function paintRoof(house, color){ house.roof.color = color return house; } var layout = {/*  - */}, house = {}; Build(layout, house); paintRoof(house, 'red');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

明らかに、 TypeErrorを返し、undefinedでroofプロパティを読み取れないと言います。 house.foofは未定義のままです（単純にビルドする時間がありませんでした）。 家が初期化されるまで何とか待たなければならず、これがいつ起こるかわかりません。



退屈な導入をおaびします。次に、この記事のトピックのコンテキストでJavaScriptを使用してこの問題を解決する方法を説明します。

アイデア

実際、多くのツールはありません。 建設会社の例に戻ると、マネージャーとして、あなたはどのプロセスが互いに依存しているかを知っています。 家でのすべての操作（塗装、内装など）は、家自体が建てられるまで不可能です。 ただし、たとえば、プールを掘ったり、フェンスを建てたり、その他のアクションを実行することは非常に可能です。 ワークフローを調整する方法は？ 明らかに、請負業者が家を建てる間、私たちはビジネスに取り掛かりますが、彼らが仕事を終えたときをどのように知るかを決める必要もあります（実際の生活でどれほどばかげているように聞こえても）。 2つのアイデアがあります。

• 家の準備ができているかどうか、定期的に請負業者に尋ねます。
• 家の準備ができたら、請負業者に知らせてください。

JavaScriptの観点から、3つのオプションがあります。

• 非同期機能の結果としてのみ変更できるシステムのステータスを定期的に確認してください。
• コールバック関数（コールバック）を登録し、非同期プロセスの終わりに制御を転送します。
• 非同期アクションの最後に、何らかの種類のハンドラーをハングさせるためにリッスンするイベントを発行します。

これらのオプションを詳しく見てみましょう。

私は、最初のオプションはタイマーと多数のチェックに基づいているため、良くないと主張します。 最も単純な場合、状態はブール変数です。 ただし、非同期関数は、2つの状態だけでなく、さらに多くの状態を持つオブジェクトの処理になります。 そして、完了した状態の各組み合わせに別々に対応する必要があります。 非同期アクションの終了時にブール変数をfalseからtrueに変更することによってのみシステム状態に影響を与えることができる3つの非同期呼び出しを想像してください。 この状況では、システムの8（2 ³ ）の一般的な状態が既に発生しています。 このようなアーキテクチャは実際には構成不可能であり、複雑なアプリケーションではレイアウトのシンプルさが決定的な要素であることがよくわかります。 状態の組み合わせをチェックすることは、特にロジックの影響を受けない場合は簡単なことではありません。 明らかに、コードのクリーンさと明確さの観点から、これは完全な悪夢です。





だから私たちのオプションは何ですか？

最初のオプションはPromiseパスです

すべてが非常に簡単です。コールバック関数を非同期関数に渡し、非同期関数は最後に呼び出します。

 function Build(layout, onComplete){ //... async onComplete(house); } Build(layout, function(buildedHouse){ return house = paintRoof(buildedHouse, 'red'); });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この方法で、遅かれ早かれ、PromiseAPIに導かれます。PromiseAPIは、非同期アクションの完了の2つの論理結果（成功の場合とエラーの場合）に応答する機能を提供します。 自分で実装しない場合、または既成のPromiseAPI実装（ Qなど）を使用する場合、一般的な実装と同様に、非同期関数の異なる関数に2つのコールバックを渡すことができます。 これにより、変更を常に監視するという問題を解決できます。 変更が行われたので、コールバック関数は自動的に起動します。

 function Build(layout, success, error){ //...   ok - true ,     return ok ? success(house) : error(new Error("-   ")); } Build(layout, function(buildedHouse){ return house = paintRoof(buildedHouse, 'red'); }, function(error){ throw(error); } );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このアプローチには明らかな欠点もあります。 まず、非同期アクションのシーケンスの場合の関数のネストがわかりにくい、たとえば、すでに3つのアクションがある場合、次のようになります。

 async1(args, function(response){ async2(response, function(response){ async3(response, function(response){ hooray(response); //   Node.js. }); }); });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、第二に、管理の柔軟性の欠如：アプリケーションの各部分を開発し、コールバックの正しい実行を保証する責任を負います。 問題は保証すらされていません。 コールバックの1つが確実に機能します。これがPromiseのポイントです 。 問題は、再び競争力のあるイベントを作成したい場合、どのコールバックが最初に機能するかわからないことですが、場合によっては重要です。 別の問題：一部のモジュールのコールバックを他のモジュールの非同期関数内に登録し、それらが機能するため、コールバックをバックドア経由でアプリケーションの外部状態に接続するか、グローバル（またはモジュール間で隣接）データを使用する必要があります。 両方のオプションは、たとえば、最高のアイデアではありません。 競合するイベントが混在しないように特別に設計されたアーキテクチャを慎重に設計する必要がありますが、より高いレベルの抽象化を使用して同様のすべてのケースに適用できます。 非同期ストリームに何らかのラッパーを作成できることがすぐにわかった場合、おめでとうございます。PromiseAPIのアイデアが思いつきました。 幸いなことに、現在、次のスタイルで記述する機能があります。

 async1.then(async2).then(async3).then(hooray);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最良の部分は、ネイティブコンポーネントを含むPromiseAPIの使用を推奨するデザインパターンをいつでも選択できることです。 最新のMV * JavaScriptフレームワークはこれに基づいています。 良い例は、Angular.jsの$ q​​サービスです。

ニシュティヤクとして、そしてあなたがニュースを追うなら、あなたはいくつかの最新のブラウザがすでにpromiseのネイティブ実装をサポートしていることに驚かないでしょう。 PromiseAPI仕様の検討はこの記事の範囲外ですが、 この記事を読んでCommon.js Promises仕様に精通することを強くお勧めします。

オプション2-パブ/サブパス

非同期関数は、イベントを発行することにより完了したことを報告します。 この場合、イベントを発行するコードの部分と、イベントに応答するコードの部分を論理的に分離します。 作成中のアプリケーションを論理的に複数のモジュールに明確に分割でき、各モジュールが厳密に定義された機能を実行するが、相互作用する必要がある場合、これは正当化される可能性があります。





一見、このアプローチは非同期メソッドにコールバック関数を登録することと大差ありませんが、主な違いは、イベントのパブリッシャーとサブスクライバー間のやり取りを自分で調整することです。これにより、ある程度の自由度が得られますが、メディエーター "）。 このアプローチの主な欠点は、イベントのオブジェクトをリッスンし、登録されたコールバックを引き起こす特定のイベントサブスクライバーが必要なことです。 これは個別のオブジェクトである必要はなく（前の例のように）、実装には多くのオプションがあります。 多くの場合、モジュール間にさまざまな種類の「論理層」があります。これは、他のモジュールのコンテキスト外でモジュールの相互作用を行う擬似モジュールです。 ただし、約束と比較して、このアプローチはより柔軟です。



厳密に言えば、これはPub / Subパターンを実装するだけの問題です。 どのようにそれを行うかはそれほど重要ではありません。 NodeJSで書いた場合は、EventEmitterに精通している必要があります。そして、クラスをイベントの発行とリッスンのメソッドを使用できるようにすることの重要性を理解してください。 ブラウザのプログラミングに関しては、かなりの数のオプションがあります。 ほとんどの場合、遅かれ早かれ、使用するフレームワークのトリガーメソッドを使用することになります。ほとんどのMV *フレームワークでは、これを簡単かつ簡単に行うことができます（および一部の:)これをまったく行わないこともできます）。 いずれにせよ、理論は十分に詳細に説明されています。 肯定的な例の1つは、モジュールファサードメディエーターパターンの組み合わせです 。これについては、 こちらを参照してください 。

設計

多かれ少なかれ大規模なアプリケーションの作成を開始するときは、アーキテクチャの論理部分を分離して、互いに別々に開発および保守できるようにする必要があります。 非同期プログラミングでは、モジュールはAPIメソッドを呼び出してすぐに結果を返さないため、モジュールへの要求の順次実行とアプリケーションの他の部分による応答の処理は基本的に不可能です。 外部からモジュール内にハンドラーを登録する機能は非常に満足のいく方法ですが、モジュール間の相互作用を拡張する予定がある場合は、「コールヘルル」に陥る可能性があることを理解する必要があります。 その一方で。 最終的なAPIを提供する非常に単純なモジュールがありますが、これは拡張が難しいため、コールバックの直接実装のアーキテクチャが要件に適合する場合があります。





一部のツールを選択するタイミングと、他のツールを選択するタイミングを理解できることが重要です。

確かに小さなアプリケーションを作成し、次のスキームを使用する必要がありました。

 var root = $("#container"); // ,     root.on("someEvent", function(){ // }); root.trigger("someEvent"); //    root
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一部のアプリケーションモジュール内にコールバックを登録せず、特に実行コンテキストに注意を払わず、アプリケーションパーツの論理的な分離を維持するために、多くのユーザーは単にDOM要素でカスタムイベントを発行し、それを他の場所でキャッチしますアプリケーションの場所と必要なアクションを実行します。 したがって、モジュールは1つの要素のみに依存しており、コールバックを登録する代わりに、追加のパラメーターをモジュールに渡すだけです。これは、リッスンするドキュメント要素です。 厳密に言えば、これはかなり議論の余地のあるプラクティスですが、アイデア自体は良いものです。 モジュールがイベントを発行し、アプリケーションがイベントをリッスンすると、多くの点で非常に便利です。

標準のPub / Subメソッドでモジュールを拡張するオブジェクトのラッパーを使用することは私にとって一般的になっています。

 var module = PubSub({ load: function(url){ ... this.emit('loaded', data); } }); module.on('loaded', function(data){ ... });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、モジュールはイベントを発行し、それ自体がサブスクライバーです。 代替アーキテクチャ-すべてのモジュールの1つのサブサブセクションは全体としてより集中化されているように見えますが、これはモジュールイベントとアプリケーションイベントの間の単なる別のレイヤーです。 ほとんどの場合、これは必要ではありません。さらに、イベントの収集とハンドラーの登録のみに関与し、これが何かによって引き起こされない場合（たとえば、アプリケーションアーキテクチャのマルチステージネスト）、そのようなリレーは本質的にファサードであると考えてはいけません。中間層。 さらに、集中型アーキテクチャに対するもう1つの言葉は、アプリケーションモジュールの数が増えるにつれて、このように競争力のあるイベントを構成することがますます難しくなるということです。 アプリケーションに、サーバーとクライアント間でのデータの同期が含まれるモジュールが含まれ、複数のクライアントが存在する可能性があり、参加者が共同の競合イベントを発行する場合、まれな状況をシミュレートしません。 サブスクリプションとパブリケーションのバスを介してのみモジュールをリンクできる場合、異種イベントのレイアウトがどのように単純化されるかをご理解いただければ幸いです。 これは、集中制御ユニットを引っ張る必要なく相互にやり取りできるコンポーネントに関して非常に便利です。

イベント駆動型アプリケーション

最近、私に関連するトピックはイベントのレイアウトです。 不快な点は、イベントが異なる場所で発生するだけでなく、異なる時間に発生することです。 特別な手法を使用せずに異種のイベントを組み合わせるのは、控えめに言っても不快です。 このすべてのために、「非常に波乱に富んだ」と説明できる特別な種類のアプリケーションがあり、多くの異なる部分で構成されています。 これらの部分は、相互にやり取りしたり、ユーザーとやり取りしたり、サーバーにデータを送信したり、単に保留状態にしたりできます。 / then / elseが組み合わせ脳爆発である場合、従来の命令を使用して、可能なすべてのイベントの組み合わせを整理しようとします。 奇妙なことに、この種のアプリケーションに適用された関数型プログラミング方法論は、人生をずっと楽にします。 さまざまなイベント間の複雑な依存関係を、使い慣れた関数型プログラミングの宣言スタイルで記述する機能を提供するライブラリがいくつかあります（Bacon.JS、Reactive Extensions-RxJSを参照）。 この記事ではこれらのライブラリを分析しません。現在、Bacon.jsに似た自己記述ライブラリを使用しているとだけ言いますが、非同期ストリームのレイアウトと破壊に重点を置いています。 コメント付きの作業コードのフラグメントを提供します。



, , ( . , : ? -.



, !