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

15

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 la collaborazione con Angular 2 (dato che è più adatto al nostro problema).

Ci occupiamo del business delle app aziendali, che al momento comprende molte tecnologie front-end (pur avendo l'intero backend RESTful) e volevamo sostituire tutto e disporre di una singola tecnologia per facilitare l'addestramento futuro e il controllo 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 la navigazione su moduli figlio / sotto-prodotti, in modo tale che il flusso di lavoro appaia come segue.

  • SuperApp

    • Autentica utente
    • Dimentica guidata password
    • Pagina pubblica accessibile senza auth
    • Utente autenticato

      • Sistema di navigazione

        • Inizio
          • Sotto-prodotto1
          • Sotto-product2
          • Sotto-prodotto3
        • Profilo

          ...

          ...

        • Gruppi

          ...

          ...

Nota che nella rappresentazione sopra, Sub-product1 e Sub-product2 sono due aree completamente diverse, con domini aziendali completamente diversi.

Quello che posso pensare in questo momento è che posso creare SuperApp come un singolo progetto Angular 2 con solo componenti e viste rilevanti per se stesso, e SuperApp è anche responsabile del caricamento di più app per bambini; Sub-product1 , Sub-product2 (ancora, diversi progetti Angular 2, con il proprio package.json , webpack config, ecc.) tramite componenti stupidi, e agiscono come una shell che fornisce routing di primo livello e un segnaposto per tenere quelle app per bambini.

Una volta, Sub-product1 viene caricato all'interno della shell, aggiungerà i propri percorsi alla rotta corrente su cui è atterrato SuperApp.

Il motivo per cui voglio la separazione è perché queste diverse app (che sono attualmente costruite usando ExtJS) hanno team dedicati che lavorano su di essa (siamo un'azienda che ha più di 500 sviluppatori), quindi se hanno i loro progetti Angular, possono gestisci i loro strumenti e dipendenze a loro piacimento senza fare affidamento sull'app per i nonni.

Ma non sono in grado di trovare da nessuna parte nei documenti Angular ufficiali o sul Web che sia possibile avere app Angular nidificate (in modo tale che il codice 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 un problema del genere.

Saranno apprezzate eventuali indicazioni o collegamenti a qualsiasi articolo pertinente.

    
posta Kushal 05.08.2016 - 07:55
fonte

2 risposte

1

Che cosa stai descrivendo lo so dal modulo therm. Quindi mi riferirò a come tale.

Non affronterò la questione se i moduli angolari di supporto siano o meno per mancanza di conoscenza del framework. Inoltre, secondo me non lo vuoi davvero. Nella mia comprensione, e mi aspetto che il tuo backend rispecchi, vuoi tagliare tutto il più piccolo possibile ( micro servizi ).

In questo caso ogni punto sul diagramma dovrebbe essere la propria app indipendente. Di sicuro devono comunicarsi l'un l'altro, secondo ogni responsabilità, per comporre la vista che hai descritto. Hai visto in che modo Google ha un URL / strumento / sistema separato da autenticare? Gmail non si preoccupa di questo, perché non è una sua responsabilità. Anche il controllo di tutti gli strumenti è centrale invece di trovarsi in ogni strumento (lo vedete sul design dei materiali). Le risorse vivono al di fuori di ogni progetto / sistema.

Facendo così ottieni una maggiore leva di riusabilità e flessibilità dei tuoi sistemi. Anche se in piccoli gruppi questo è insostenibile a causa della complessità e del tempo. Ora è compito tuo scoprire dove cade il tuo 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.

    
risposta data 27.10.2018 - 22:12
fonte
1

Un'opzione: puoi "link rigido" (anziché utilizzare i collegamenti SPA) alle app secondarie e fare in modo che ciascuna subapp condivida una dipendenza per il wrapper del sito.

    
risposta data 27.12.2018 - 01:14
fonte