約 1 年間開発を続けてきた私のプロジェクトで、requirejs の使用を開始したいと考えています。
プロジェクトは asp.net で、マスターページには約 50 のスクリプトがあり、その半分はプロジェクト用のカスタム スクリプトであり、そのほとんどは公開モジュール パターンを使用して作成され、残りの半分はサード パーティのスクリプトと jquery プラグインです。
ページにはインラインの JS コードもたくさんあります。
プロジェクトをリファクタリングするための最良の戦略を教えていただければ幸いです。開発チームの残りの部分をブロックしないように、段階的に行う何らかの方法かもしれません。
AMD モジュール パターンを使用する正当な理由は 1 つだけです。それは、JS コードを管理しやすいモジュールに分割することで、開発者の正気を守ることです。
健全性を維持しながら、コンパクトで効率的なページを提供できる方法は 1 つしかありません。AMD ツリーを「構築」する必要があります。そうしないと、すべての小さなモジュールが HTTP Get リクエストの山になり、アプリの速度が低下します。
特定のケースで「組み込みの AMD ツリー」を使用することの副作用の 1 つは、縮小された JavaScript の恩恵を受ける可能性があることです。アプリは既に gzip されたサーバーによって提供されていますが、JavaScript を縮小するとさらに小さくなります。さらに、個別の静的 JS ファイルは、サーバーによって非常に短いキャッシュ設定が割り当てられている可能性がある aspx ファイルと比較して、キャッシュ署名が優れています。
AMD ツリーを「構築」する方法:
2. 次に、これらのファイルを AMD モジュールに変換します。アプリを再テストします。
3. 次に、ツリーで AMD ツリー オプティマイザーを実行して、すべての AMD モジュールをパックする 1 つの長い JS ファイルを取得します。そのモジュールに対してアプリを再テストします。
AMD ビルド ツールには確立されたリーダーがいます: https://github.com/jrburke/r.js
しかし、最初に試してみることをお勧めします: http://prunejs.com/
最初のものは巧妙な構成と多くの忍耐を必要とします。PruneJS は構成を必要としませんが、r.js よりも柔軟性が低くなります。
「AMD ツリーを構築する」ということを約束しない限り、AMD には行かないでください。それはそれだけの価値はありません。