it-swarm.com.de

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

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

Wir beschäftigen uns mit Unternehmensanwendungen, die derzeit aus vielen verschiedenen Front-End-Technologien bestehen (und gleichzeitig über das gesamte Backend-RESTful verfügen). Wir wollten alles ersetzen und über eine einzige Technologie verfügen, um zukünftige Schulungen und Qualitätskontrollen zu vereinfachen.

Angesichts der Art 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, aber das Produkt selbst lebt in einer einzigen URL.

Beispiel;

Nennen wir mein Produkt SuperApp.

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

  • SuperApp

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

      • Navigationssystem

        • Zuhause
          • Unterprodukt1
          • Unterprodukt2
          • Unterprodukt3
        • Profil

          ...

          ...

        • Gruppen

          ...

          ...

Beachten Sie, dass in der obigen Darstellung Sub-product1 Und Sub-product2 Zwei völlig unterschiedliche Bereiche mit völlig unterschiedlichen Geschäftsbereichen sind.

Was ich mir jetzt vorstellen kann, ist, dass ich SuperApp als ein einzelnes Angular 2-Projekt erstellen kann, das nur Komponenten und Ansichten enthält, die für sich selbst relevant sind, und SuperApp ist auch für das Laden verantwortlich mehrere untergeordnete Apps; Sub-product1, Sub-product2 (Wieder verschiedene Angular 2 Projekte mit eigener package.json, webpack Konfiguration usw.) über dumm -Komponenten und fungieren als Shell, die Routing auf oberster Ebene und einen Platzhalter für diese untergeordneten Apps bereitstellt.

Sobald Sub-product1 In die Shell geladen ist, werden eigene Routen an die aktuelle Route angehängt, auf der SuperApp gelandet ist.

Der Grund, warum ich mich trennen möchte, ist, dass an diesen verschiedenen Apps (die derzeit mit ExtJS erstellt werden) dedizierte Teams arbeiten (wir sind ein Unternehmen mit mehr als 500 Entwicklern). Wenn sie also ihre eigenen Angular Projekte haben können sie ihre Werkzeuge und Abhängigkeiten nach ihren Wünschen verwalten, ohne sich auf die App der Großeltern verlassen zu müssen.

Aber ich kann in offiziellen Angular -Dokumenten oder im Web nirgendwo finden, ob es überhaupt möglich ist, Angular Apps zu verschachteln (so dass Framework-Code währenddessen geteilt wird) Abhängigkeiten von untergeordneten Apps werden nur dann vollständig isoliert und geladen, wenn die App sie benötigt oder wenn es einen alternativen Ansatz zur Lösung eines solchen Problems gibt.

Anleitungen oder sogar Links zu relevanten Artikeln sind willkommen.

17
Kushal

Eine Option: Sie können eine feste Verbindung (anstatt SPA-Links zu verwenden) zu den Unter-Apps herstellen und jede Unter-App eine Abhängigkeit für den Site-Wrapper freigeben lassen.

1
jchook

Was Sie beschreiben, weiß ich durch das Modul therm. Also werde ich mich darauf beziehen.

Ich werde mich nicht mit der Frage befassen, ob angular Unterstützungsmodule für mangelndes Wissen über das Framework. Auch meiner Meinung nach wollen Sie das nicht wirklich. Nach meinem Verständnis, und ich gehe davon aus, dass Ihr Backend reflektiert, Sie möchten alles auf die kleinsten Teile schneiden, die Sie können (Mikrodienste).

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

Auf diese Weise erzielen Sie einen höheren Hebel für die 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 hinfällt. Alles in Mikrodiensten und Trennung, alles in einem Päckchen oder irgendwo in der Mitte. Und Module, falls verfügbar, würden Sie in jedem Punkt verwenden.

1
CesarScur