Wie vermeide ich einen Alptraum der Modulabhängigkeitskette, der durch transitive Abhängigkeiten verursacht wird?

Viele (die meisten?) AngularJS-Leute scheinen sich dafür einzusetzen, AngularJS-Apps in viele Module aufzuteilen.

Brian Ford gibt in seinem Blog bereits an, dass das Verpacken nach Schichten (Controller, Service usw.) eine "dumme" Vorstellung ist, also werde ich nicht einmal dorthin gehen. (Siehe http://briantford.com/blog/huuuuuge-angular-apps .)

Angenommen, Sie modularisieren eine App nach Funktionen. Möglicherweise haben Sie ein Benutzermodul und ein Nachrichtenmodul sowie das Standard- App- Modul zum Laden dieser Funktionsmodule. Sie platzieren die Routen in Bezug auf die Benutzerfunktionalität sorgfältig im Benutzermodul und die nachrichtenbezogenen Routen im Nachrichtenmodul . Meiner Meinung nach haben Sie in JEDEM Funktionsmodul eine Abhängigkeit von ngRoute erstellt . Also sollte jedes Modul "ngRoute" in seinem Abhängigkeitsarray auflisten, oder?

Leider macht es AngularJS allzu leicht, das zu vermasseln. Wenn Ihre App Modul lädt beiden Benutzer und Nachrichten , aber nur Benutzer Listen „ngRoute“ als Abhängigkeit, ist es egal , zur Laufzeit: $ routeProvider wird immer noch in der Config - Funktion in injiziert wird Nachrichten , im Wesentlichen gelöst, das durch den Anwender des Moduls Abhängigkeit von ngRoute .

Mein Problem könnte das allgemeine Muster eines "App" -Moduls sein, das verschiedene Funktionsmodule lädt / referenziert. Das Muster macht für mich Sinn, ebenso wie transitive Abhängigkeiten. Problematisch ist, dass die spezielle Implementierung von Angular Fälle maskieren kann, in denen ein Modul nicht einmal indirekt auf seine Modulabhängigkeiten verweist. Das Modul funktioniert möglicherweise im Kontext einer bestimmten App (da das Modul von einem anderen "App" -Modul referenziert wird, das auch direkt oder indirekt auf seine Abhängigkeiten verweist). Wenn Sie das Modul jedoch in eine andere App kopieren, schlägt dies fehl aufgrund fehlender Abhängigkeiten.

Ich habe den Eindruck, dass die meisten Leute die Tatsache, dass das Benutzermodul jetzt im Wesentlichen eine Abhängigkeit des Nachrichtenmoduls ist, nicht besonders berücksichtigen würden . Es ist jedoch ein Problem, an dem ich nur schwer vorbeischauen kann. Wenn wir diese verwirrenden Abhängigkeiten zwischen Feature-Modulen wahrscheinlich erstellen, verringert dies für mich den Nettovorteil der Modularisierung erheblich, und ich hätte lieber nur ein einziges App- Modul, das alle Komponenten für alle Features in der App kapselt.

Ich würde nicht viele kleine Module befürworten, deren Gewinn zu gering ist. Das Winkelmodul ist wirklich kein großes Modulsystem. Sie bieten keinen echten Namespace, sie sind auch nicht streng, wenn ein anderes aktives Modul Ihre Abhängigkeit "importiert", funktioniert es normalerweise (wie Sie erwähnt haben) usw. Aus diesem Grund hilft es Ihnen nicht, Ihre Abhängigkeiten pro Modul zu "dokumentieren" wird unvollständig sein.

Halten Sie sich einfach an sehr grobe / große Module. Ich habe gelernt, sie meistens als Konfiguration eines Abhängigkeitsinjektionscontainers zu betrachten, nicht so sehr als Mittel zum "Komponieren". Alle diese "Module" verletzen normalerweise sowieso YAGNI, als ob Sie die App jemals ohne ausführen würden. Überlegungen zur Wiederverwendung sind meist ein Versprechen, das selten erfüllt wird.

Heutzutage verwende ich TypeScript-Module, um meinen Code zu partitionieren. Winkelmodulabhängigkeiten, die ich größtenteils für echte Sachen von Drittanbietern reserviere.