AngularおよびRequireJSプロジェクトビルダーと構築に関するいくつかの考え

プロジェクトビルダーで最も不便な点は何ですか？ そう！ 自分でアセンブリを記述する必要があること。 グラント/グール/ウェブパック、プラグインを備えたシャーマンを勉強するには、設定が数百行になったら設定をモジュールに分割し、数か月後にすべてが機能することを喜ばせ、プロジェクトに重大な変更が現れたら、この沼に登ります。



私もこのすべてにうんざりしているので、 コレクターはこれらの欠点を欠いて書いた。 gulpfile.jsは次のようになります。

var gulp = require('gulp'); var arjs = require('arjs-builder')(); gulp.task('build', arjs.build); gulp.task('test', arjs.test); gulp.task('default', arjs.run);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

彼らは自分たちでプロジェクトをコピーしました。あなたは二度とそこに登ることはできず、アセンブリが何であるかを永遠に忘れてしまいます。

唯一学ぶべきことは、次の3つのコマンドです。

 gulp #,    gulp build #  gulp test # 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

localhost：7000を開き、ローカルバージョンのサイトとbuild





フォルダーをお楽しみください build





すでにバージョンを置いています。



-しかし、テンプレートはどうですか、jsで実装する必要がありますか？

-もちろん！ すべてが期待どおりに実装されています。

-そして、私はより少ない、sass、スタイラスでスタイルを書きます、それらはコンパイルされなければなりませんか？

-彼らが書いたように書く、すべてが奇跡的に動作します。

-CSSの写真には以下が含まれますか？

-ずっと前に、すべてがCSSにありました。 5つ星ホテルのようにすべて含まれています。

-そして、保存したファイルをモジュールに分割しますか？

-ビルドフォルダーを確認します。 すべてのモジュール？ ファイルの内容に基づいた一意の名前を使用していますか？ ここで、あなたは心配していました！

-そして、何か他のものがあります...

「それも機能します。」



しかし、これはどのように可能ですか？ これについては記事で検討します。 最後に、RequireJSの理由を説明します

プロジェクト構造

あなたはいつも何かを犠牲にしなければなりません。 私たちの場合、これらはプロジェクト構造に課せられた制限であり、アセンブリ結果に直接影響します。 しかし、ここでは泣いてはなりませんが、喜ぶ必要があります。「最大限の柔軟性とコントロールが必要です。すべてを自分で書きます」などの悪を犠牲にしたからです。 見てみましょう。正直に言って、ほとんどの開発者は、単一ページアプリケーションのフロントエンドアーキテクチャについてほとんど考えていないという結論に至ります。誰も何も分析していません）。 そして、それはウェブ開発者にとって必要ですか？ このために、彼は仕事を得た？



トピックに近い。 コレクターは、R​​equireJSとAngularJSに基づくプロジェクトを対象としています。 ただし、彼は純粋なJSと理論的には他のフレームワークの両方でプロジェクトに取り組んでいます。



アプリケーションの作業ディレクトリは次の構造になります。

 projects/ ├──project1/ ├──project2/ ├──project3/ ├──files/ ├──vendor/ ├──compiled/ ├──build/ ├──index.html ├──lib.js └──lib.css .bowerrc bower.json package.json gulpfile.js
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

project1..3



プロジェクトのあるフォルダー。 プロジェクトでは、サイトの個別のセクションまたは個別のサイトについて説明します。 プロジェクトは、異なるフレームワークを使用して、または使用せずに作成できます。 プロジェクトの場合、汎用のindex.htmlまたは独自のindex.htmlを使用できます。 中間レベルのアプリケーションには、少なくとも3つのプロジェクトがあります。

• main
  
  
  
  -メインサイト
• admin
  
  
  
  -管理者
• old-browser
  
  
  
  は、最も原始的なJSで書かれた古いブラウザのスタブです

大規模なアプリケーションでは、他のプロジェクトで使用されるメインモジュール（ルーティング、承認、リソースの操作など）が組み立てられるlib



プロジェクトが表示される場合があります。



一部のプロジェクトでは、新しいバージョンのサイト（スムーズな移行を整理するため）、A / Bテスト用のアセンブリ、一時的なランディングページなどを作成する価値があります。



files



は、CSS（ファイルサーバーへの転送の候補）に挿入されないfiles



が含まれます。 残りは2GBのビデオであってもbase64に変換され、スタイルに挿入されます。 プロジェクトはインターフェースのみを記述するため、コンテンツは他の場所から取得する必要があります。

bowerのライブラリは、 vendor



コピーされます。

コンパイルには、ローカル作業用の一時ファイル（スタイル、ベンダーライブラリ）が含まれます。

build



収集されたプロジェクトはサーバーにアップロードする準備ができています。



index.html



の例はこちらにあります 。 gulpfile.jsのように、変更されることはありません。

-しかし、そこにスクリプトを追加したり、分析を接続するにはどうすればよいですか？

-構成内またはプロジェクト内の対応するモジュール内のスクリプトの配列を通じて。 分析アプリケーションとメタタグを使用した例が、 デモアプリケーションに特別に追加されました。

抽象マーケティング代理店は、Yandex.Metrica、googleAnalitycs、googleTagManager、vkontakte、mailru、doubleClick ...カウンターを追加するように要求します。すべてのユーザーは、独自のスクリプトをインデックスに配置し、独自のshit-ipreframeまたはshit-pictureを作成する必要があります1ピクセル。 紳士よ、あなたは死んでいないのですか？ インデックスでたわごとができると思いますか？ 現在、これらのすべての新興企業は個別のモジュールに囲まれており、設定に許可がある場合にのみ接続されます。 ローカル開発中に多くの左利きのクエリを見たくないですか？

lib.js



は、メインフレームワークをロードする前に使用できる最も必要なメソッドであるマイクロフレームワークがあります。 ブラウザーの定義、ユーザーロケール、読み込みスクリプトなど。 理論的には、このファイルを変更する必要はないはずですが、これを保証するほどデバッグされていません。



次に、単一プロジェクトの単純化された構造を検討します。

 _config/ ├──default.yaml ├──dev.yaml └──production.yaml module1/ ├──_tests ├──someFolder1/ │ ├──some.js │ ├──style.sass │ └──template.html ├──someFolder2/ └──config.js module2/ module3/ bootstrap.js requireconfig.js
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後から行きましょう。

requireconfig.js



ライブラリファイルをプロジェクトに接続します

bootstrap.js



プロジェクトファイルが含まれます。 標準の作業スキームrequire.js

module1..3



プロジェクトモジュール。 アセンブリ中、各モジュールは個別のファイルにアセンブルされます。

_tests



は、現在のフォルダー内のファイルに関連するテストです。 spec.js



終わるファイルspec.js



テストと見なされます。

config.js



は、対応するモジュールの依存関係を記述します

someFolder



は任意の構造を持つことができます（主なことは、すべての依存関係が記述されていることです）

template.htmlまたはstyle.css / .sass / .scss / .less / .stylusがスクリプトファイルの横にある場合、テンプレートキャッシュまたはコンパイル済みスタイルファイルに追加されます。 非常に単純なルール。 コレクターは何もドラッグしませんが、スクリプトがロードされる順序でスクリプトファイルに関連するもののみを取得します。



最も興味深いのは_config





さまざまな環境の構成がここに保存されます。 サポートされている形式は、json、json5、hjson、cson、yamlです。 IDEがjson5のサポートを開始したらすぐに、すべての例を転送し、サポートされている唯一の形式のままにします。 default



は、すべての環境に共通のdefault



説明されます。 残りの構成はデフォルトです。



目的の構成でプロジェクトをビルドするには、最初のパラメーターとして名前を指定する必要があります

 gulp --qa gulp build --production
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デフォルトはdev



です。



構成ファイルの構造：

 { public: { ... }, //,     project.config localhost: { webserver: { ... }, //  - manifest: { ... } //     }, build: { /*      */ ... manifest: { ... }, //     modules: { ... }, //    ,   vendor    mangle: true,         copy: { ... } //   - ,  robots.txt }, vendor: { ... }, //   . ,   bootstrap  angularStrap     }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

構成は、おそらくビルダーの最も難しい部分です。 それを提示するには、 より複雑でシンプルなアプリケーションの例を見てみるのがよいでしょう。

なぜ同じRequireJSなのか？

もちろん、モジュールが必要に応じてロードされ、一度にすべてがロードされるわけではありません...誰かが言うでしょう。 しかし、違います。



組み立てられたプロジェクトの構造は次のとおりです。

 vendor-f8acc4024d.js #800 vendor-9dcd7dad8d.css #100 common-95dafc6502.js #200 homepage-2979ff1937.js #30 news-ebf043aeac.js #10 ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

考えてみると、プロジェクトベンダー（ライブラリコンポーネントを含むモジュール）の最大の重みは約1MB（500KB以上）であるという結論に達することができます。 同時に、プロジェクトの開始前にすべてのライブラリをロードする必要があるため、遅延ロードを整理することはできません。 もちろん、ライブラリごとにファイルに分割することもできますが、それらをダウンロードすると、すべてのブラウザースレッドが詰まり、他のプロジェクトファイルの読み込みが遅れますが、これは大きなメリットにはなりません。 ベンダーがすべてのモジュールの変更を最小限に抑えるため、ほとんどの場合、キャッシュから取得されます。



次のサイズはメインモジュールで、プロジェクト全体の一般的なロジックと一般的なスタイルが記述されています。 また、めったに変更されません。



次に、パーティションおよびさまざまなビジネスロジック用の10〜20のモジュールが登場します。 彼らは頻繁に変化しますが、重さの重さです。 さらに、合計すると、それらの重量はすべてのライブラリの重量に匹敵します。



読み込みを高速化し、要素をすばやく表示するには、スタイルファイルをベンダーとメインモジュールから別々のモジュールに移動するのが理にかなっています（アセンブリを使用すると、CSSをJSに含めることと、モジュールごとに読み込み順序を個別に構成できます）。 下の図の例では、支払いシステムの重いアイコンが含まれているため、支払いモジュールのスタイルをレンダリングできます 。



次に、プロジェクトの最初のロードがどのように行われるかを見てみましょう（gzipが有効になっているため、ファイルの重みは小さくなります）。





ベンダーがロードしている間、ほとんどすべてのプロジェクトリソースがロードすることができます。 つまり、遅延読み込みモジュールには意味がありません。 さらに、ユーザーが別のセクションに移動した場合、10KBのファイルの読み込みを待機する必要があるため、サイトの速度が低下します。 つまり、RequireJSは大規模プロジェクトでも小規模プロジェクトでも不要です。



それで、なぜそれが使用されますか？ 開発専用。



その主な利点は、依存関係を簡単に接続し、さまざまなプロジェクトからコンポーネントを借用できることです。 たとえば、管理者は同じルーティング、同じリソース、同じエラー処理を使用します。 メインプロジェクトから必要なモジュールを簡単に接続できるのに、なぜコピーアンドペーストするのですか？ これにより、新しいプロジェクトを可能な限り迅速に展開できます。



副次的な利点は、ローカル作業にコレクターが必要ないことです（実行中のサーバーのみ）。 スクリプトはコンパイルされません。 結果はすぐに利用でき、大規模なプロジェクトでは多大な費用がかかります。 しかし、Babel、ES6、Coffee、TypeScriptはどうでしょうか？ しかし、まさか。 アセンブリは、生産中の大規模および中規模プロジェクトで使用するために作成されました。 大学の研究やホームページを持っているのに、どうして集会が必要なのですか？ そして、もしこれらすべてが深刻なプロジェクトであるが、生産中であるなら...もう一度心を動かしてみましょう。あなたは雇用主を犠牲にして新しいテクノロジーを学んでいるだけです。 同じ理由で、htmlプリプロセッサはサポートされていません（これは非常に単純ですが）。 Web開発者はJSとHTMLを知っています。今日人気のある他の技術とは異なり、明日は誰もがそれらを忘れています。

それでは、どのようにすべてを開始しますか？

bowerとgulpをグローバルにインストールします。

 npm i -g bower npm i -g gulp
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

簡易または本格的なデモプロジェクトをダウンロードし、そのフォルダーに次のコマンドを入力します。

 npm i bower i gulp
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

localhost：7000を開き、賞賛します。



次を入力します。

 gulp build --production gulp
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

localhost：7200を開き、ビルドフォルダーに表示される本番用にアセンブルされたバージョンを賞賛します。



何か機能しませんでしたか？

そのため、npmはモジュールをロードまたはロードしませんでした。 問題がKarmaにある場合は、Karmaとそのすべてのプラグインが同じnode_modulesフォルダーにあることを確認してください。 node-sassが見つからない場合は、ノードを最近更新した可能性が高いため、すべてのプラグインを再インストールします。 フォルダを変更する権限がありません-別のコンソールを試してください。 インストール時にエラーが発生しますが、すべてが機能する/機能しない-Windowsがあります。

今後の計画

• RequireJSなしでビルドを収集することは可能です。 これで、余分な17Kは許容可能です（プロジェクト全体の重量と比較して）。
• IPAの簡素化。
• 他のフレームワークのサポート（単独ではありません）。
• パフォーマンス...現在、すべてのプロセスはRAMで実行されていますが、livereloadは変更されたモジュールのスタイルのみをコンパイルします。
• 多言語プロジェクトのサポート。
• コードからドキュメントを生成します。
• AngularJSのプロジェクトアーキテクチャに関する記事を書いてください。 現在、一般的な構造のみが影響を受けており、プロジェクト内のモジュールとその作成方法を説明していません。
• 一般に、C ++ですべてを書き直し、gulpを取り除きます。 （おそらくこの世にはない）

ご清聴ありがとうございました。批判を聞く準備ができています。