Pe măsură ce cererea crește, funcțiile proiectului devin mai complexe. În acest moment, trebuie să modularizezi proiectul și să pachetezi componentele, instrucțiunile și pipeline-urile în blocuri funcționale coezive, ceea ce este perfect pentru a explora subrutele și încărcarea leneșă a modulelor în Angular4.
În dezvoltarea anterioară, o funcție simplă de rutare a fost implementată în modulul rădăcină, care poate fi rezumată în următorii trei pași:
1、在app.module.ts文件中加载路由库，并且在@NgModule中引入RouterModule.forRoot方法，其中，appRoutes是路由数组，它定义了具体的路由规则。
2. Adaugă o bară de navigație la componenta shell, unde comanda routerLink indică destinația rutei, iar routerLinkActive adaugă stil css etichetei selectate
3. Adaugă o comandă router-outlet la șablonul componentei shell, iar vederea va fi afișată acolo
Acum vreau să implementez subrute și încărcarea leneșă a modulelor pe această bază.
RouterModule.forRoot() și RouterModule.forChild()
Obiectul RouterModule oferă două metode statice: forRoot() și forChild() pentru a configura informațiile de rutare.
Metoda RouterModule.forRoot() este folosită pentru a defini informațiile principale de rutare în modulul principal, iar RouterModule.forChild() este similară cu metoda Router.forRoot(), dar poate fi aplicată doar în modulele de funcționalitate.
Adică, forRoot() este folosit în modulul rădăcină, iar forChild() este folosit în submodul.
Fiul său, Lu Ru
Să presupunem că există două pagini sub pagina noastră /settingssettings, /settings/profile și /settings/password, care reprezintă pagina de profil și pagina de schimbare a parolei, respectiv. setând ca un bloc de funcții separat, care poate fi încapsulat într-un modul de funcționalitate. Are propriile rute independente, iar rutele pentru paginile de profil și parolă pot fi setate ca subrute.
În modulul SettingsModule folosim metoda forChild(), deoarece SettingsModule nu este modulul principal al aplicației noastre.
O altă diferență majoră este că setăm calea principală a modulului SettingsModule pe o cale goală (''). Pentru că dacă setăm calea la /settings, va corespunde cu /settings/settings. Specificând o cale goală, se potrivește cu calea /settings.
Încărcare leneșă: loadChildren
Configurați informațiile de rutare ale modulului de setare în modulul rădăcină AppModule:
Proprietatea LoadChildren cu încărcare leneșă este folosită aici. În loc să importe SettingsModule în AppModule, proprietatea loadChildren îi spune rutei Angular să încarce modulul SettingsModule conform căii configurate de proprietatea loadChildren. Aceasta este aplicarea specifică a funcției de încărcare leneșă a modulului: când utilizatorul accesează calea /settings/**, modulul corespunzător SettingsModule va fi încărcat, ceea ce reduce dimensiunea resursei încărcate la pornirea aplicației.
Valoarea proprietății loadChildren este alcătuită din trei părți:
Sunt necesare căi relative pentru importarea modulelor
#分隔符
Exportă numele clasei modulului
Modul CommonModule
Am menționat că vreau să introduc modulul CommonModule în modulul de funcționalitate, dar nu am observat inițial că voiam să-l introduc în modulul de funcționalitate și, ca urmare, eroarea de pagină a fost raportată în timpul rutării:
core.es5.js:1020 ERROR Error: Uncaught (in promise): Error: Template parse errors:
Nu se poate lega de 'ngClass' deoarece nu este o proprietate cunoscută a 'div'ului.
Nu se poate lega de 'ngForOf' deoarece nu este o proprietate cunoscută a lui 'p'.
Legarea proprietății ngForOf nu este folosită de nicio directivă pe un șablon încorporat. Asigură-te că numele proprietății este scris corect și toate directivele sunt listate în "@NgModule.declarations".
Nu se poate lega de 'ngIf' deoarece nu este o proprietate cunoscută a 'div'.
......
După ce am verificat mult timp, am descoperit că problema s-a întâmplat pentru că nu am introdus CommonModule în modulul de funcționalitate, iar după ce l-am introdus, aceste erori au dispărut.
CommonModule oferă multe instrucțiuni utilizate frecvent în aplicații, inclusiv NgIf și NgFor. Mai precis, directivele precum NgIf sunt declarate în CommonModule din @angular/common.
Am importat modulul BrowserModule în modulul rădăcină AppModule, care a importat CommonModule și l-a reexportat. Rezultatul final este că, atâta timp cât imporți BrowserModule, vei primi automat instrucțiunile din CommonModule.
Importul unui BrowserModule face ca toate componentele, directivele și pipeline-urile expuse de modul să fie disponibile direct în orice șablon de componentă din AppModule, fără pași suplimentari plictisitori. Dar nu importa BrowserModule în niciun alt modul. Modulele de funcționalități și modulele de încărcare leneșă ar trebui importate în CommonModule în schimb. Nu necesită reinițializarea întregului furnizor la nivel de aplicație. Dacă imporți un BrowserModule într-un modul de încărcare leneș, Angular afișează o eroare.
Acestea sunt câteva dintre problemele și rezumatele pe care le-am întâlnit în ultimele două zile folosind subrutele Angular și încărcarea leneșă.
|
Postat pe 13.06.2019 13:13:10
|
|
|
|
