Con l'aumento della domanda, le funzioni del progetto diventano più complesse. Al momento, devi modularizzare i componenti, istruzioni e pipeline del progetto e del package in blocchi funzionali coesivi, il che è perfetto per esplorare le sottoroute e il carico pigro dei moduli in Angular4.
Nello sviluppo precedente, una semplice funzione di routing è stata implementata nel modulo radice, che può essere riassunta nei seguenti tre passaggi:
1、在app.module.ts文件中加载路由库，并且在@NgModule中引入RouterModule.forRoot方法，其中，appRoutes是路由数组，它定义了具体的路由规则。
2. Aggiungere una barra di navigazione al componente della shell, dove il comando routerLink punta alla destinazione del percorso, e routerLinkActive aggiunge uno stile css all'etichetta selezionata
3. Aggiungi un comando router-outlet al template del componente della shell e la visuale verrà visualizzata lì
Ora voglio implementare sottoroute e caricamento pigro dei moduli su questa base.
RouterModule.forRoot() e RouterModule.forChild()
L'oggetto RouterModule fornisce due metodi statici: forRoot() e forChild() per configurare le informazioni di instradamento.
Il metodo RouterModule.forRoot() viene utilizzato per definire le informazioni principali di routing nel modulo principale, mentre RouterModule.forChild() è simile al metodo Router.forRoot(), ma può essere applicato solo nei moduli di funzionalità.
Cioè, forRoot() viene usato nel modulo root e forChild() è usato nel sottomodulo.
Suo figlio Lu Ru
Supponiamo che ci siano due pagine sotto la nostra pagina impostazioni /settings, /settings/profile e /settings/password, che rappresentano rispettivamente la pagina profilo e la pagina di cambio password. impostato come blocco funzione separato, che può essere racchiuso in un modulo di caratteristiche. Ha percorsi propri indipendenti, e i percorsi per le pagine profilo e password possono essere impostati come sottoroute.
Nel modulo SettingsModule usiamo il metodo forChild(), perché SettingsModule non è il modulo principale della nostra applicazione.
Un'altra differenza importante è che impostiamo il percorso principale del modulo SettingsModule su un percorso vuoto (''). Perché se impostiamo il percorso a /settings, corrisponderà a /settings/settings. Specificando un percorso vuoto, corrisponde al percorso /settings.
Caricamento pigro: loadChildren
Configura le informazioni di routing del modulo di impostazione nel modulo radice AppModule:
Qui viene utilizzata la proprietà LoadChildren con caricamento lento. Invece di importare il SettingsModule nell'AppModule, la proprietà loadChildren indica alla rotta Angular di caricare il modulo SettingsModule secondo il percorso configurato dalla proprietà loadChildren. Questa è l'applicazione specifica della funzione di caricamento pigra del modulo: quando l'utente accede al percorso /settings/**, verrà caricato il corrispondente modulo SettingsModule, riducendo così la dimensione della risorsa caricata all'avvio dell'applicazione.
Il valore della proprietà di loadChildren è composto da tre parti:
Sono necessari percorsi relativi per importare i moduli
#分隔符
Esporta il nome della classe modulo
Modulo CommonModule
Ho detto che volevo introdurre il modulo CommonModule nel modulo feature module, ma non avevo notato che volevo introdurlo nel feature module all'inizio, e di conseguenza l'errore di pagina è stato segnalato durante il routing:
core.es5.js:1020 ERROR Error: Uncaught (in promise): Error: Template parse errors:
Non si può associare a 'ngClass' perché non è una proprietà nota di 'div'.
Non può essere legato a 'ngForOf' perché non è una proprietà nota di 'p'.
Property binding ngForOf non viene utilizzato da alcuna direttiva su un template incorporato. Assicurati che il nome della proprietà sia scritto correttamente e che tutte le direttive siano elencate nelle "@NgModule.declarations".
Non si può legare a 'ngIf' perché non è una proprietà nota di 'div'.
......
Dopo aver verificato a lungo, ho scoperto che era perché non avevo introdotto CommonModule nel modulo feature e, dopo averlo introdotto, questi errori sparivano.
CommonModule fornisce molte istruzioni comunemente utilizzate nelle applicazioni, inclusi NgIf e NgFor. Più precisamente, direttive come NgIf vengono dichiarate nel CommonModule da @angular/common.
Abbiamo importato il modulo BrowserModule nel modulo radice AppModule, che ha importato il CommonModule e lo ha riesportato. Il risultato finale è che, finché importi il BrowserModule, riceverai automaticamente le istruzioni nel CommonModule.
L'importazione di un BrowserModule rende tutti i componenti, le direttive e le pipeline esposti dal modulo disponibili direttamente in qualsiasi template di componente sotto l'AppModule senza ulteriori passaggi tediosi. Ma non importare il BrowserModule in nessun altro modulo. I moduli feature e i moduli di caricamento pigro dovrebbero essere importati in CommonModule invece. Non richiedono la riinizializzazione dell'intero provider a livello applicativo. Se importi un BrowserModule in un modulo di caricamento pigro, Angular genera un errore.
Questi sono alcuni dei problemi e riassunti che ho incontrato negli ultimi due giorni usando le subroute Angular e il caricamento lento.
|
Pubblicato su 13/06/2019 13:13:10
|
|
|
|
