1
推移的な依存関係によって引き起こされるモジュール依存関係チェーンの悪夢を回避するにはどうすればよいですか？
多くの（ほとんど？）AngularJSの人々は、AngularJSアプリを多くのモジュールに分割することを提唱しているようです。 Brian Fordは彼のブログで、レイヤー（コントローラー、サービスなど）ごとのパッケージ化は「ばかげた」概念であると既に述べているので、ここでは説明しません。（http://briantford.com/blog/huuuuuge-angular-appsを参照してください。） ただし、アプリを機能ごとにモジュール化するとします。おそらく、これらの機能モジュールをロードするための標準のappモジュールに加えて、usersモジュールとmessagesモジュールがあります。ユーザー機能に関連するルートをユーザーモジュールに、メッセージ関連のルートをメッセージモジュールに慎重に配置します。今、私の心の中で、あなたはngRouteの各機能モジュールに依存関係を作成しました。したがって、各モジュールは、依存関係の配列に「ngRoute」をリストする必要がありますよね？ 残念ながら、AngularJSはそれを台無しにすることを非常に簡単にします。あなたの場合はアプリのモジュールがロードの両方のユーザーとメッセージが、唯一のユーザーのリストを依存関係として「ngRoute」、それは実行時に問題ではない：$ routeProviderはまだで、あなたの設定機能の中に注入されるメッセージの本質的により解決された、ユーザーのモジュールのngRouteへの依存。 私の問題は、さまざまな機能モジュールをロード/参照する「アプリ」モジュールの一般的なパターンにある可能性があります。推移的な依存関係と同様に、このパターンは私にとって意味があります。問題なのは、Angularの特定の実装が、モジュールがそのモジュールの依存関係を間接的に参照しない場合をマスクできることです。モジュールは特定のアプリのコンテキストで機能する可能性があります（モジュールが別の「アプリ」モジュールによって参照されており、その依存関係も直接または間接的に参照されているため）。ただし、モジュールを別のアプリにコピーすると、失敗します。依存関係がないため。 ほとんどの人は、usersモジュールが基本的にmessagesモジュールの依存関係になっているという事実をあまり考慮しないだろうという印象を受けます。しかし、それは私が過去を見るのに苦労している問題です。私にとって、機能モジュール間にこれらの混乱する依存関係を作成する可能性がある場合、それはモジュール化の正味の利点を実際に減少させ、アプリのすべての機能のすべてのコンポーネントをカプセル化する単一のアプリモジュールを用意するだけです。