Erstellen einer großen Angular 2-App mit mehreren kleinen Apps

Nach langen 3-monatigen Debatten und Nachforschungen bei der Wahl zwischen React (mit Redux) und Angular 2 hat sich das Front-End-Team in meinem Unternehmen für Angular 2 entschieden (da es für unser Problem besser geeignet ist).

Wir beschäftigen uns mit Unternehmensanwendungen, die derzeit aus vielen verschiedenen Front-End-Technologien bestehen (während das gesamte Back-End REST-fähig ist), und wir wollten alles ersetzen und eine einzige Technologie haben, um die zukünftige Schulung und Qualitätskontrolle zu vereinfachen.

Angesichts der Beschaffenheit unseres Produkts ist es riesig und es gibt Module, die an sich eine andere Domäne darstellen und als eigenständige App erstellt werden können, das Produkt selbst jedoch unter einer einzigen URL gespeichert ist.

Beispiel;

Nennen wir mein Produkt SuperApp.

Als Benutzeroberfläche verfügt SuperApp über ein Standard-Anmeldesystem und die Navigation zu untergeordneten Modulen / Unterprodukten, sodass der Workflow wie folgt aussieht.

• SuperApp

  • Benutzer authentifizieren
  • Passwort vergessen Assistent
  • Öffentliche Seite ohne Authentifizierung zugänglich

  • Authentifizierter Nutzer

    • Navigationssystem

      • Zuhause
        • Unterprodukt1
        • Unterprodukt2
        • Unterprodukt3

      • Profil

        ...

        ...

      • Gruppen

        ...

        ...

Beachten Sie, dass in oben Darstellung, Sub-product1und Sub-product2sind zwei völlig verschiedene Bereiche, ganz andere Geschäftsbereiche haben.

Momentan kann ich mir vorstellen, dass ich SuperApp als einzelnes Angular 2-Projekt mit nur für sich relevanten Komponenten und Ansichten erstellen kann. SuperApp ist auch für das Laden mehrerer untergeordneter Apps verantwortlich. Sub-product1, Sub-product2(wiederum verschiedene Angular 2-Projekte, die ihre eigene package.json, webpackKonfiguration usw. haben) über dumme Komponenten und fungieren als Shell, die Routing auf oberster Ebene und einen Platzhalter für diese untergeordneten Apps bereitstellt.

Sobald Sub-product1es in die Shell geladen ist , hängt es seine eigenen Routen an die aktuelle Route an, auf der SuperApp gelandet ist.

Der Grund für die Trennung ist, dass diese verschiedenen Apps (die derzeit mit ExtJS erstellt werden) von dedizierten Teams bearbeitet werden (wir sind ein Unternehmen mit mehr als 500 Entwicklern). Wenn sie also über eigene Angular-Projekte verfügen, können sie ihre Tools verwalten und Abhängigkeiten nach Belieben, ohne sich auf die App der Großeltern zu verlassen.

In offiziellen Angular-Dokumenten oder im Web kann ich jedoch nirgendwo feststellen, ob es überhaupt möglich ist, geschachtelte Angular-Apps zu haben (so dass der Framework-Code gemeinsam genutzt wird und Abhängigkeiten von untergeordneten Apps nur dann vollständig isoliert und geladen werden, wenn die App vorhanden ist braucht es), oder ob es einen alternativen Ansatz gibt, um ein solches Problem zu lösen.

Jede Anleitung oder sogar Links zu relevanten Artikeln wird geschätzt.

Was Sie beschreiben, weiß ich durch das Modul therm. Also werde ich mich als solches bezeichnen.

Ich werde mich nicht mit der Frage befassen, ob eckige Unterstützungsmodule für mangelnde Kenntnisse über das Framework geeignet sind oder nicht. Meiner Meinung nach willst du das auch nicht wirklich. Meines Erachtens, und ich gehe davon aus, dass Ihr Backend dies widerspiegelt, möchten Sie alles auf die kleinstmöglichen Teile zerschneiden ( Micro Services ).

In diesem Fall sollte jeder Punkt in Ihrem Diagramm eine eigene unabhängige App sein. Sie müssen sicher miteinander kommunizieren, entsprechend der Verantwortung, die von Ihnen beschriebene Ansicht zu verfassen. Sie haben gesehen, wie Google eine separate URL / Tool / System zur Authentifizierung hat? Google Mail ist das egal, da es nicht in seiner Verantwortung liegt. Auch das Enthäuten aller Werkzeuge ist von zentraler Bedeutung, anstatt sich in jedem Werkzeug zu befinden (dies sehen Sie beim Materialdesign). Die Assets befinden sich außerhalb jedes Projekts / Systems.

Auf diese Weise erzielen Sie einen höheren Grad an Wiederverwendbarkeit und Flexibilität Ihrer Systeme. Obwohl dies in kleinen Teams aufgrund der Komplexität und der Zeit unhaltbar ist. Jetzt ist es Ihre Aufgabe, herauszufinden, wo Ihr Fall fällt. Alles in Mikrodienstleistungen und Trennung, alles in einem Paket oder irgendwo in der Mitte. Und Module, falls verfügbar, würden Sie in jedem Punkt verwenden.

Eine Option: Sie könnten eine "feste Verknüpfung" (anstatt SPA-Verknüpfungen zu verwenden) zu den Unter-Apps herstellen und jede Unter-App eine Abhängigkeit für den Site-Wrapper teilen.