web-dev-qa-db-ja.com

AngularJS：複数のng-appsを使用したWebアプリケーションの構造化

ブロゴスフィアには、AngularJSアプリの構造化ガイドラインに関する以下のような記事が多数あります。

ただし、ガイドラインとベストプラクティスについてまだ出会っていない1つのシナリオは、複数の「ミニスパ」アプリを含む大規模なWebアプリケーションがあり、ミニスパアプリがすべて一定量のコードを共有している場合です。

同じページで複数のng-app宣言をしようとする場合については言及していません。むしろ、独自の一意のng-app宣言を持つ大規模なサイトのさまざまなセクションを意味します。

Scott Allenが OdeToCode ブログに書いているように：

私が十分に対処できていないシナリオの1つは、複数のアプリが同じ優れたWebアプリケーションに存在し、クライアントでいくつかの共有コードを必要とするシナリオです。

あなたが指摘できる、推奨されるアプローチ、回避すべき落とし穴、またはこのシナリオの適切なサンプル構造はありますか？

更新-2015年9月10日
興味深い組織戦略を持つ1つのプロジェクトは、MEAN.JSとそのモジュールフォルダーです。
https://github.com/meanjs/mean
https://github.com/meanjs/mean/tree/master/modules

別の例は、ASP.NETミュージックストアSPAの例です。 https://github.com/aspnet/MusicStorehttps://github.com/aspnet/MusicStore/tree/master/src/MusicStore.Spa/ng-apps

designweb-applicationsangularjs
40
mg1075

これが私が使用するデザインです。私が作成した2つのより大きなプロジェクトで役立ち、これまでのところどのような障害にも遭遇していません。

フォルダ構造

your-project/
  apps/
    global.html
    app1/
      index.html
      app1.module.js
      app1.js
      parts/
        foo.js
        foo.html
        ...
    app2/
  libs
    lib1/
      lib1.module.js
      parts/
        directive1.js
        directive1.html
    lib2/
  third-party/
  • apps/app1/index.htmlのリクエストが届いたときに/app1を見つけるようにサーバーウェブフレームワークを設定します。わかりやすいURLを使用します（例：the-first-application/ではなくapp1/）。必要に応じてサーバーテクノロジーを使用してマッピングします。
  • サーバーテクノロジーにはベンダーインクルードが含まれているため（以下を参照）、global.htmlをindex.htmlに含める必要があります。
  • それぞれのアプリで必要なアセットをindex.htmlに含めます（下記を参照）。
  • ng-appに<div ui-view></div>とルートindex.htmlを配置します。
  • すべてのアプリとライブラリは個別のangularモジュールです。
  • すべてのアプリは、angularモジュール定義と依存関係リストを含む<app-name>.module.jsファイルを取得します。
  • すべてのアプリは、モジュールの構成と実行ブロックを含む<app-name>.jsファイル、およびその一部としてルーティング構成を取得します。
  • すべてのアプリは、アプリケーションのコントローラー、ビュー、サービス、ディレクティブを含むpartsフォルダーを取得します特定のアプリにとって意味のある構造で。 controllers/、views/などのサブフォルダーは、スケーリングされないためYMMVなので、役に立ちません。
  • ライブラリはアプリと同じ構造に従いますが、（明らかに）不要なものは除外します。

使用するアプリ内のサービスとディレクティブから始めます。別のアプリでも何かが必要になるとすぐに、ライブラリにリファクタリングします。 all-directiveまたはall-servicesライブラリだけでなく、機能的に一貫したライブラリを作成してください。

資産

私はリリースビルド用にJSファイルとCSSファイルの両方を縮小しますが、開発中は縮小されていないファイルを操作します。これをサポートする設定は次のとおりです。

  • global.htmlにグローバルに含まれるベンダーを管理します。このようにして、SPA間を移動するときに、重いものをキャッシュからロードできます。キャッシングが適切に機能することを確認します。
  • SPAごとのアセットはindex.htmlで定義されています。これには、アプリ固有のファイルと使用されるライブラリのみを含める必要があります。

上記のフォルダー構造により、縮小化ビルドステップに適したファイルを簡単に見つけることができます。

8
theDmi

シングルページアプリ（SPA）は、本当に大きなアプリケーションとメインアプリケーション内の複数のミニSPAで提案する方法で使用することを意図したものではありません。すべてを事前にロードする必要があるため、最大の問題はページのロード時間です。

これに取り組む1つの方法は、個々のSPAに移動するナビゲーションページを使用することです。ナビゲーションページはかなり軽量になり、選択した内容に基づいて一度に1つのSPAのみをロードします。各SPA内にナビゲーションリンクを備えたリンクバーを提供できるので、ユーザーは別のエリアに移動する必要があるときに常にナビゲーションページに戻る必要はありません。

このアプローチを使用すると、SPA間で情報を永続化するときにいくつかの課題が生じる可能性があります。しかし、SPAが意図していないことについて話しているのです。クライアント側のデータの永続化に役立つフレームワークがいくつかあります。最初に思い浮かぶのはそよ風ですが、他にもあります。

レイアウトについて-特定のニーズに応じて、いくつかのプログラマーの質問が大規模プロジェクトのレイアウトに対応します。私は これ と これ に出くわしました。 SPAには、これらの質問ですでに回答されているものを超えてアプリケーションレイアウトに影響を与えるような魔法のようなものはありません。

とはいえ、プロジェクトごとに最適な方法はいくつかあります。 angularシードプロジェクトで提供されているベースレイアウトを使用することをお勧めします。カスタムパッケージとソースコード用に提供されているものとは別のフォルダーを作成します。そして、ソースフォルダー内でプロジェクトレイアウトを使用しますそれはあなたのニーズにとって理にかなっています。

7
user53019