Livello di modularizzazione dell'applicazione Angular 2

1

la mia domanda è correlata a Angular 2 Modules (@NgModule).
In precedenza ho lavorato con angular 1.5.8 su enormi applicazioni aziendali e mi sono abituato alle pratiche Angular 1.x.

Sfondo importante:
In questo momento sto sviluppando qualcosa di più della singola applicazione. Sarà più simile alla piattaforma di business. Impostiamo convenzioni di piattaforma comuni per lo styling, la denominazione, la struttura, il REST, ecc. Tutta la piattaforma è composta da un'applicazione principale e alcune app più piccole strettamente correlate. Ora creerò la versione di base dell'applicazione e mi piacerebbe che fosse facile da personalizzare (forse le parole migliori sono "da decorare") per i clienti. Mi piacerebbe anche che ogni componente fosse il più possibile riutilizzabile. L'applicazione più piccola può parzialmente utilizzare gli stessi componenti dell'interfaccia utente (e non sto parlando solo dei componenti del modulo condiviso).

La mia domanda è:

  • È una buona idea fornire un modulo separato per ciascun componente significativo? - per "componente significativo" Capisco i componenti puntati da Rotte e componenti condivisi (generici e privi di stato).

Gli esempi di documenti angolari descrivono moduli funzione, ma tutti i contenuti all'interno di questi moduli non sono incapsulati con moduli, usano solo componenti che vengono aggiunti al modulo dichiarazioni: [] elenco.

Pro:

  • Capacità di esporre le dipendenze dei componenti in un unico punto - supponiamo che un componente utilizzi altri componenti. Se abbiamo tutte le dipendenze elencate nelle importazioni: [], non è necessario scorrere il modello dei componenti per trovarli tutti
  • Abbiamo un migliore controllo sui nostri domini funzionali (presumo che possiamo trattare il modulo come dominio funzionale) - il codice è meglio incapsulato perché i moduli ci forniscono il meccanismo di esportazione in modo da poter dichiarare facilmente membri pubblici e privati. Riduce l'overhead della comunicazione del team in quanto è chiaramente visibile quale componente è pubblico e che è solo un componente di supporto.
  • Creiamo più codice riutilizzabile - Se vogliamo utilizzare un particolare componente in un'altra applicazione (che appartiene anche alla piattaforma) è più comodo averlo incapsulato nel modulo - a prima vista vediamo quali sono i necessari aggiuntivi dipendenze che dovrebbero anche essere spostate nella nostra applicazione.
  • Possiamo mantenere la struttura delle directory più piatta : è davvero un vantaggio?
  • Possiamo limitare le dimensioni delle dichiarazioni del modulo - migliora la leggibilità.

Contro:

  • Più codice - dobbiamo dichiarare il modulo per (quasi) ogni componente
    EDIT:
  • Abuso del meccanismo @NgModule - non sono sicuro, ma posso immaginare che potrebbe aumentare il tempo di bootstrap del modulo con carico pigro

Esempio di struttura del progetto

--/user-groups //user-groups is lazy loaded module
   --/user-groups-list
      --user-groups-list.component.ts // Public component
      --user-groups-list-filter-input.component.ts  // Private component - strong relation with user-groups-list.component
      --user-groups-list.module.ts
      --user-groups-list.html
      --user.groups-list.css
--user-groups.component.ts
--user-groups.module.ts // Router points to this module
--user-groups-routing.module.ts // Routing inside of  user-groups
--user-groups.service.ts // It's component service
--user-groups.html
--user.groups.css
    
posta MPrzy 30.01.2017 - 12:20
fonte

0 risposte

Leggi altre domande sui tag