Composizione di grandi app Angular 2 con più piccole app all'interno

Dopo lunghi 3 mesi di dibattiti e ricerche nella scelta tra React (con Redux) e Angular 2, il team front-end della mia azienda ha concluso di andare con Angular 2 (dato che è più adatto al nostro problema).

Siamo nel business delle app aziendali, che attualmente comprende molte diverse tecnologie front-end (pur avendo l'intero backend RESTful), e volevamo sostituirle tutte e disporre di un'unica tecnologia per facilitare la formazione futura e il controllo di qualità.

Data la natura del nostro prodotto, è vasto e ci sono moduli all'interno, che sono di per sé un dominio diverso e possono essere realizzati come app standalone ma il prodotto stesso vive in un singolo URL.

Esempio;

Chiamiamo il mio prodotto come SuperApp.

Come interfaccia utente, SuperApp ha un sistema di accesso standard e navigazione verso moduli / sottoprodotti secondari, in modo che il flusso di lavoro appaia come segue.

• SuperApp

  • Utente autenticato
  • Dimentica la procedura guidata per la password
  • Pagina pubblica accessibile senza autent

  • Utente autenticato

    • Sistema di navigazione

      • Casa
        • Sotto-product1
        • Sotto-product2
        • Sotto-prodotto3

      • Profilo

        ...

        ...

      • gruppi

        ...

        ...

Si noti che nella rappresentazione sopra, Sub-product1e Sub-product2sono due aree completamente diverse, con domini aziendali completamente diversi.

Quello che mi viene in mente in questo momento è che posso creare SuperApp come un singolo progetto Angular 2 con solo componenti e viste che sono rilevanti per se stesso, e SuperApp è anche responsabile del caricamento di più app figlio; Sub-product1, Sub-product2(di nuovo, diversi progetti Angular 2, con i propri package.json, webpackconfigurazione, ecc.) tramite componenti stupidi, e fungono da shell che fornisce il routing di livello superiore e un segnaposto per contenere quelle app figlio.

Una volta, Sub-product1viene caricato all'interno della shell, aggiungerà le proprie rotte alla rotta corrente alla quale è arrivata SuperApp.

Il motivo per cui voglio la separazione è perché queste diverse app (che sono attualmente costruite utilizzando ExtJS) hanno team dedicati che ci lavorano (siamo un'azienda con oltre 500 sviluppatori), quindi se hanno i loro progetti angolari, possono gestire i loro strumenti e dipendenze a loro piacimento senza fare affidamento sull'app Grand Parent.

Ma non sono in grado di trovare da nessuna parte nei documenti angolari ufficiali o sul Web che se sia possibile avere app angolari nidificate (in modo tale che il codice del framework sia condiviso mentre le dipendenze delle app figlio sono completamente isolate e caricate solo quando l'app ne ha bisogno) o se esiste un approccio alternativo per risolvere tale problema.

Saranno apprezzate tutte le indicazioni o anche i collegamenti ad articoli pertinenti.

Quello che stai descrivendo lo so dal modulo therm. Quindi mi riferirò a come tale.

Non ho intenzione di affrontare la questione se i moduli di supporto angolare siano o meno per mancanza di conoscenza sulla struttura. Inoltre, secondo me non lo vuoi davvero. Nella mia comprensione, e mi aspetto che il tuo back-end si rifletta, vuoi tagliare tutto al minimo possibile ( micro servizi ).

In questo caso ogni punto sul diagramma dovrebbe essere la propria app indipendente. Devono sicuramente comunicare tra loro, in base a ciascuna responsabilità per comporre il punto di vista che hai descritto. Hai visto come Google ha un URL / strumento / sistema separato da autenticare? A Gmail non interessa questo perché non è una sua responsabilità. Anche il pattinaggio di tutti gli strumenti è fondamentale invece di trovarsi in ogni strumento (lo vedi nella progettazione dei materiali). Le risorse vivono al di fuori di ogni progetto / sistema.

In questo modo si ottiene una maggiore leva di riusabilità e flessibilità dei sistemi. Anche se in piccoli team questo è insostenibile a causa della complessità e del tempo. Ora tocca a te capire dove cade il caso. Tutto in micro servizi e separazione, tutto in un pkg o da qualche parte nel mezzo. E i moduli, se disponibili, sono qualcosa che useresti all'interno di ogni punto.

Un'opzione: è possibile "hard link" (invece di utilizzare i collegamenti SPA) con le app secondarie e fare in modo che ciascuna subapp condivida una dipendenza per il wrapper del sito.