När efterfrågan ökar blir projektets funktioner mer komplexa. Vid det här laget behöver du modulera projektet och paketera komponenter, instruktioner och pipelines till sammanhängande funktionsblock, vilket är precis rätt för att utforska subroutes och lat laddning av moduler i Angular4.
I den tidigare utvecklingen har en enkel routningsfunktion implementerats i rotmodulen, vilket kan sammanfattas i följande tre steg:
1、在app.module.ts文件中加载路由库，并且在@NgModule中引入RouterModule.forRoot方法，其中，appRoutes是路由数组，它定义了具体的路由规则。
2. Lägg till en navigationsfält i skalkomponenten, där routerLink-kommandot pekar på ruttens destination, och routerLinkActive lägger till css-stil på den valda etiketten
3. Lägg till ett router-outlet-kommando i mallen för shellkomponenten, och vyn visas där
Nu vill jag implementera underrutter och lat laddning av moduler på denna grund.
RouterModule.forRoot() och RouterModule.forChild()
Objektet RouterModule tillhandahåller två statiska metoder: forRoot() och forChild() för att konfigurera routningsinformationen.
Metoden RouterModule.forRoot() används för att definiera huvudroutningsinformationen i huvudmodulen, och RouterModule.forChild() liknar metoden Router.forRoot(), men kan endast tillämpas i funktionsmoduler.
Det vill säga, forRoot() används i rotmodulen och forChild() används i delmodulen.
Hans son Lu Ru
Anta att det finns två sidor under vår /settings-sida, /settings/profile och /settings/password, som representerar profilsidan respektive lösenordsändringssidan. Setting som ett separat funktionsblock, som kan kapslas in i en funktionsmodul. Den har egna oberoende rutter, och rutterna för profil- och lösenordssidorna kan ställas in som underrutter.
I SettingsModule-modulen använder vi metoden forChild(), eftersom SettingsModule inte är huvudmodulen i vår applikation.
En annan stor skillnad är att vi sätter huvudsökvägen för SettingsModule-modulen till en tom väg (''). För om vi sätter sökvägen till /settings, kommer den att matcha /settings/settings. Genom att ange en tom väg matchar den /settings-vägen.
Lat laddning: laddaBarn
Konfigurera routningsinformationen för inställningsmodulen i rotmodulen AppModule:
LoadChildren-egenskapen lat laddning används här. Istället för att importera SettingsModule till AppModule, säger loadChildren-egenskapen åt Angular-rutten att ladda SettingsModule-modulen enligt den väg som loadChildren-egenskapen konfigurerar. Detta är den specifika tillämpningen av modulens lazy loading-funktion; när användaren går åt /settings/**-vägen kommer motsvarande SettingsModule-modul att laddas, vilket minskar storleken på den laddade resursen när applikationen startar.
loadChildrens egendomsvärde består av tre delar:
Relativa vägar för att importera moduler krävs
#分隔符
Exportera namnet på modulklassen
CommonModule-modul
Jag nämnde att jag ville introducera CommonModule-modulen i feature-modulen, men jag märkte inte att jag ville introducera den i feature-modulen först, och som ett resultat rapporterades sidfelet under routing:
core.es5.js:1020 ERROR Error: Uncaught (in promise): Error: Template parse errors:
Kan inte binda till 'ngClass' eftersom det inte är en känd egenskap hos 'div'.
Kan inte binda till 'ngForOf' eftersom det inte är en känd egenskap hos 'p'.
Egendomsbindande ngForOf används inte av någon direktiv på en inbäddad mall. Se till att egendomsnamnet är stavat korrekt och att alla direktiv listas i "@NgModule.declarations".
Kan inte binda till 'ngIf' eftersom det inte är en känd egenskap hos 'div'.
......
Efter att ha kollat länge upptäckte jag att det berodde på att jag inte introducerade CommonModule i feature-modulen, och efter att ha introducerat det försvann dessa fel.
CommonModule tillhandahåller många vanligt använda instruktioner i applikationer, inklusive NgIf och NgFor. Mer precist deklareras direktiv som NgIf i CommonModule från @angular/common.
Vi importerade BrowserModule-modulen i rotmodulen AppModule, som i sin tur importerade CommonModule och exporterade den igen. Slutresultatet är att så länge du importerar BrowserModule får du automatiskt instruktionerna i CommonModule.
Att importera en BrowserModule gör alla komponenter, direktiv och pipelines som exponeras av modulen tillgängliga direkt i vilken komponentmall som helst under AppModule utan ytterligare tidskrävande steg. Men importera inte BrowserModule till någon annan modul. Funktionsmoduler och lazy loading modules bör importeras till CommonModule istället. De kräver inte ominitiering av hela applikationsnivåleverantören. Om du importerar en BrowserModule i en lazy loading module ger Angular ett felmeddelande.
Det här är några av problemen och sammanfattningarna jag stött på de senaste två dagarna med hjälp av Angular-subroutes och lat laddning.
|
Publicerad på 2019-06-13 13:13:10
|
|
|
|
