スケーラブルなTypeScriptアプリケーションの構築。 パート1-モジュールの非同期読み込み

この記事のアイデアは、オフィスで30度の厳しい仕事をし、「最新のWebアプリケーションをどのように構築する必要があるか」というトピックに関する深い反省とホリバーを経て生まれました。



そして、アイデアは、Habréのタスクに取り組む私のプロセスを述べるために私に来ました。 そして、私はそれを細部まで把握し、コミュニティの知識に貢献します。



この記事では何について説明しますか？ モジュラーアーキテクチャを実装し、モジュール、非同期イベントモデルを非同期にロードし、特定のイベントが発生したときにモジュールの状態を更新する、（ではない）大規模なTypeScriptアプリケーションを作成します。 この記事は、私の行動と思考の日記と日記として機能します。 私の個人的な目標は、いくつかの実用的なプロトタイプを作成し、その経験を後で実際のプロジェクトで使用できるようにすることです。 コードは可能な限り正確に記述され、実際の開発の要件に近いものになります。 説明は、後ほど私の指導の下で働いている後輩によって読まれるかのように与えられます。



記事は細かく分割されますが、できるだけ早く公開裁判にかけます。 最初の部分は、問題の一般的な定式化、モジュール、およびそれらの非同期ロードに専念します。



それで、私とコミュニティにこれらの約束を与え、AC / DCをオンにして、私の考えを集めて、私は先に進みます。



パート2： スケーラブルなTypeScriptアプリケーションの構築。 パート2-イベント、または自分の自転車を再発明する価値がある理由



パート2.5： スケーラブルなTypeScriptアプリケーションの構築-パート2.5。 バグとデリゲートに取り組む

使用済みソフトウェアおよびその他のコメント

この記事では、Visual Studio Express 2012 for Webをすべての最新の更新を含む作業ツールとして使用します。 その理由は、今日で適切なTypeScriptをサポートしている唯一のIDEです。



TypeScript自体について。 TS 0.8.3を使用した3か月の経験から、TSは数万行のコードを備えた非常に優れたWebアプリケーションを作成するための本当に有効なツールであることがわかります。 静的コード分析は、エラーの数を実際に1桁減らします。 また、ほぼ完全なクラシックOOP、言語レベルでの実際のモジュール性により、Require.jsおよびNode.js、Visual StudioのIntelliSenseとの透過的な統合が可能になり、実際、イデオロギーは明らかにC＃を与えてくれます。 TSからJSへの透過的な変換により、ソースマップが存在していても、ソースマップの助けがなくてもコードを簡単にデバッグできます。 この記事を書くには、最新バージョン-ジェネリックおよびその他の機能を備えた0.9を使用します。



Require.jsを使用して非同期読み込みを実装します。 Node.jsは、サーバー側のシミュレーションに使用されます。



JQuery 1.10（IE8との互換性が必要）およびUnderscore.jsは、「標準ライブラリ」としてプロジェクトに含まれます。 私たちのインターフェースの基礎は、Backbone.jsです。 標準のTS（jQuery）ディストリビューションとDefinitelyTypedプロジェクト（github.com/borisyankov/DefinitelyTyped（Require.js、Underscore、Backbone、Node.js））のヘッダーd.tsファイルを使用します。



WinAmpは、AC / DCのプレイに使用されます。

TypeScriptについて少し

TSプログラムは、* .tsおよび* .d.tsファイルのセットで構成されています。 これらは、C ++の* .cppおよび* .hファイルの類似物として表すことができます。 つまり 前者には実際のコードが含まれ、後者には同じ名前の実装ファイルが提供するインターフェースが記述されています。 TSヘッダーのみで開発する場合、d.tsファイルは必要ありません。 また、d.tsは実行時にコンパイルおよび使用されません。 ただし、既存のJSコードを記述するにはd.tsファイルが不可欠です。 なぜなら TSは完全にJSに変換され、任意のJSコードを完全に使用できますが、コンパイラはJSで使用される型、変数、および関数について知る必要があります。 D.tsファイルは、この説明の目的を果たすだけです。 これ以上詳しくは述べませんが、すべてTS仕様にあります。



一般に、example.tsをコンパイルするとき、次のファイルを作成できます。

• example.d.ts-他のプロジェクトで使用するヘッダーファイル
• example.js-ランタイムで使用するJS
• example.map.js-デバッグ用のソースマップ

プロジェクト構造

Visual StudioでTypeScriptプロジェクトを作成します。







CodePlexで公開するすべてのソース： tsasyncmodulesexampleapp.codeplex.com 。



デフォルトコードを追加し、2番目のプロジェクト-サーバーを作成し、必要なすべてのソースライブラリファイルを接続して、次の構造を取得します。







実践では、共有ライブラリのd.tsファイルは、プロジェクトと同等に最適であることが示されています。 後でテストを記述するときに非常に役立ちますが、別の時間について、および複数のプロジェクトが同じライブラリを使用する場合についても同様です。



ここでは、Visual Studioを使用して、または使用せずにTypeScriptプロジェクトをコンパイルする方法について少し説明する必要があります。 最初のケースでは、スタジオは開発者のためにすべてを行い、ファイルへのリンクがない場合、ファイルを1つずつコンパイラーに渡します。 つまり すべてのtsファイルは常にコンパイルされます。 コマンドラインからプロジェクトをビルドする場合、他のすべてのファイルへのリンクを持つファイルでアセンブリを開始する必要があります。 通常、////>を含むプロジェクトルートにBuild.d.tsファイルを作成します。 アセンブルする必要があるすべてのプロジェクトファイルにリンクし、コンソールを介してコンパイラに渡します。 この方法により、TSコンパイラの設定をスタジオの現在のプラグインよりもはるかに柔軟に管理することができます。これは、今後必要になるでしょう。



Node.exeと完全なTS配布キットが追加され、プロジェクトに慣れる際にスタジオや他のインストール済みソフトウェアに縛られないようになりました。 スタジオとの簡単な起動と統合のためのCmdファイル。後で説明します。

トレーニングタスクの説明

教育的な例として、いくつかの独立したインターフェイスコンポーネント、サーバーにデータをアップロードするための中間層、および暴力的なアクティビティをシミュレートする偽のサーバーで構成されるサイト上のパーソナルメッセージングシステム用のシンプルなクライアントを作成します。 サーバーとの通信は、安らかなサービスを介して行われますが、高品質の記述は主なタスクではありません。 彼らはちょうど動作するのに十分です。 システムには2つの画面があります。最後の3つのメッセージの短いリストと、本格的なクライアントの画面です。 それらを切り替えることができるメニューもあります。 認可など この記事は検討しません。



画面は完全に独立したモジュールであり、互いを認識しませんが、データアクセスレイヤーを認識します。 すべての画面とデータアクセスオブジェクトは別々のモジュールにラップされ、非同期にロードされ、イベントマネージャーを介してイベントを発行およびサブスクライブすることにより相互に通信します。 出版社/購読者のパターンによる。

モジュラーロードの構成



すべてが非常に簡単です。 デフォルトで受け取ったクライアントプロジェクトのApp.tsファイルに、次のコードを追加します。

export class App { public static Main(): void { alert('Main'); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロジェクトのルートにRequireJSConfig.tsファイルを作成します。

 /// <reference path="../Lib/require.d.ts" /> /// <reference path="App.ts" /> require(["App"], function(App: any) { App.App.Main(); });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Default.htm：

 <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8" /> <title>TSAsyncModulesExampleApp</title> <link rel="stylesheet" href="app.css" type="text/css" /> <script src="js/jquery-1.10.1.min.js"></script> <script src="js/underscore-min.js"></script> <script src="js/backbone.js"></script> <script src="js/require.js" data-main="RequireJSConfig"></script> </head> <body> </body> </html>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アプリケーションを起動します。







おめでとうございます、非同期にロード可能なモジュールを備えたアプリケーションが手に入りました。



私たちが行ったことをさらに詳しく見てみましょう。



まず、TSでファイルがどのようにコンパイルされるかを詳しく説明します。 ファイルにエクスポートディレクティブが含まれている場合、これはコンパイラ設定に応じて、CommonJSまたはAMDモジュールに一意にコンパイルされることを意味します。 VSのデフォルトでは、コンパイルはAMD形式で行われます。これは、Require.jsを使用するコンテキストでは便利です。 TSは、AMDモジュールをラップするための「気味の悪い」手動コードを記述する必要を完全に排除し、依存関係の正しいインストールを処理します。 これは、App.tsで観察される動作です。

 define(["require", "exports"], function(require, exports) { var App = (function () { function App() { } App.Main = function () { alert('Main'); }; return App; })(); exports.App = App; }); //@ sourceMappingURL=App.js.map
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

RequireJSConfig.tsにはエクスポートディレクティブが含まれておらず、通常の「フラット」JSにコンパイルされます。

 /// <reference path="../Lib/require.d.ts" /> /// <reference path="App.ts" /> require(["App"], function (App) { App.App.Main(); }); //@ sourceMappingURL=RequireJSConfig.js.map
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コメントは、デバッグ目的でのみコードに残ります。 デバッグアプリケーションビルドモードがあります。 リリース構成では、すべてのコメントが消去されます。



しかし、私たちのバー...モジュールに戻ります。 何が起こった：

1. default.htmをロードしました
2. Cssおよび静的に設定されたjsファイルがロードされました。これは、主観的な意見では、非同期にロードする意味がありません。 それらは私たちが作成するほとんどすべてのモジュールに必要です。
3. アイテム2のjsの中で、require.jsがロードされました
4. Require.jsは、data-main = "RequireJSConfig"属性の値を読み取り、対応するJSファイルを読み込みました。これは開始ファイルとして扱われます。
5. RequireJSConfigでは、グローバルコンテキストで最初と最後にrequireメソッドを使用します。 さらに、すべてのモジュール呼び出しは他のモジュールからのものでなければなりません。
6. require関数では、Appモジュール（最初のパラメーター）を読み込んだ後、同じ名前の変数として読み込んだモジュールを転送するコールバックを呼び出す必要があると言います。 ここでは、良心との取引に進み、TSでそれを類型化しません。 この場所では、TSのモジュール化のイデオロギーと、非同期スクリプト読み込みのマネージャーとしてのRequire.jsの特定の実装との間に矛盾があります。 詳細は以下をご覧ください。
7. Require.jsはAppモジュールをロードします。 モジュールの命名規則の詳細については、Require.jsのドキュメントをご覧ください。 つまり、ルートからのパスを示します。これは、デフォルトで使用するサイトのルートとは異なるファイル拡張子を指定せずに指定できます。 次に、RequireJSはhead.appendChild（）を使用して、各依存ファイルをスクリプトタグとしてロードします。 必要なモジュールは最後にロードされます、つまり 依存関係の後、つまり、すべての依存関係が常にロードされることを常に確認できることを意味します。 Require.jsとTSは、この問題で完全に一貫した方法で機能します。 TSの構文とコンパイルプロセスは、このシナリオに特に適合しています。
8. requireメソッドに渡されたコールバックは、AppモジュールのAppクラスであるMainの静的メソッドを呼び出します。
9. 呼び出されたアラート（「メイン」）;

requireメソッドのコールバックパラメータは、このコンテキストではTSコンパイラに知られていないため、タイプされていません。 類型化するには、次の形式のTSコンストラクトを使用する必要があります。

 import App = require('App');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この設計は、他のモジュールをロードするためにモジュールのコンテキストでのみ使用でき、AMD / CommonJSモジュールラッパーに対応する依存関係を形成します。 ラッパーなしの通常のフラットコード、つまり 矛盾が生じます。 つまり、TSはモジュールコード生成の分野でRequire.jsと完全に一貫していますが、最初のモジュール読み込みスクリプトをサポートしていません。 したがって、この状況で残っているのは、バニラJSのスタイルで古き良きアプローチを使用することです。

追加モジュールをダウンロードする

そこで、Mainメソッドと呼ばれる最初のモジュールをロードすると、アプリケーションが動作を開始しました。 教育TKによると、任意の数のモジュールをロードできる必要があります。 ただし、ダウンロードを開始する前に、TSのモジュールとは何かを理解する必要があります。

• まず、アプリケーションの自律的な部分であり、関数と変数を外部にエクスポートするモジュールパターンを実装するコードです。 さらに、実装全体が外部から隠されています。 実際、これは最も純粋な形式のカプセル化です。
• 第二に、モジュールをロードした後、変数に割り当てられます。 つまり オブジェクトとして使用できます。 実際、モジュールはJSの観点からはオブジェクトです。
• 第三に、モジュールはファイルです。
• 第4に、モジュールはTSの名前空間です。 純粋な名前空間を実装する他のモジュール内で、エクスポートできないモジュールが宣言されている場合があります。 つまり モジュールのネストレベルの数に制限はありませんが、トップレベルモジュールのみがAMD / CommonJSモジュールに変換され、スタンドアロンファイルに持ち込まれます。

実際、モジュールは一度にすべてです。 モジュールの使用もあいまいです。 確かに言えることは、モジュールがアプリケーションを自律的で再利用可能なコンポーネントに分割し、それが私たちの目標を完全に満たすということです。



新しいファイルFramework / Events.tsを作成します。これは、将来、抽象イベントモデルの実装の開始点として使用します。

 export interface IEventPublisher { On(); Off(); Trigger(); } export class EventPublisherBase implements IEventPublisher { On() { } Off() { } Trigger() { } constructor() { alert('EventPublisher'); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これまでのところ、すべてのメソッドは単なるスタブです。 仕事の原則は私たちにとって重要です。



App.tsの変更：

 import Events = require('Framework/Events'); export class App { public static Main(): void { var e = new Events.EventPublisherBase(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

モジュール読み込みディレクティブがあります：

 import Events = require('Framework/Events');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パスはルートから示されます。 上記のように、モジュールは変数に割り当てられます。 次に、アラートを宣言したコンストラクターで、Events名前空間からEventPublisherBaseクラスの新しいインスタンスを作成します。



この場合、Events変数は強く型付けされています。 コンパイラは、ロード可能なモジュールのタイプを厳密に監視します。 コンパイラーはモジュール内の型制御のための参照ディレクティブを必要としないが、正しいコンパイルのためにそれを必要とすることに注意すべきです。 つまり コンパイラはそれなしでは依存関係を追跡できません。 現在、VSはコンパイラの代わりに、明示的なファイル名に置き換えて作業を行います。 これを解決するには、前述のBuild.d.tsファイルを作成し、それに関するコンパイルを開始します。

 /// <reference path="Framework/Events.ts" /> /// <reference path="App.ts" /> /// <reference path="RequireJSConfig.ts" />
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンパイルに使用できるサンプルcmdファイル（Build-Client.cmd）は、ソリューションのルートに添付されています。



実際、非同期読み込みに関してはそれだけです。 すべてが非常にシンプルでシンプルです。



私のグラフォマニアン作品がコミュニティにとって興味深いものになることを願っています。 記事の次の部分では、抽象的なイベントモデルの構築と、非同期Webアプリケーションで使用する理由を検討する予定です。



最後まで読んでくれてありがとう！