С нарастването на търсенето функциите на проекта стават по-сложни. В момента трябва да модулизирате проекта и пакетирането на компонентите, инструкциите и конвейерите в цялостни функционални блокове, което е точно както трябва, за да изследвате подмаршрути и лениво зареждане на модули в Angular4.
В предишната разработка беше реализирана проста маршрутизираща функция в коренния модул, която може да се обобщи в следните три стъпки:
1、在app.module.ts文件中加载路由库，并且在@NgModule中引入RouterModule.forRoot方法，其中，appRoutes是路由数组，它定义了具体的路由规则。
2. Добавете навигационна лента към компонента shell, където командата routerLink сочи към дестинацията на маршрута, а routerLinkActive добавя css стил към избрания етикет
3. Добавете команда router-outlet към шаблона на shell компонента и изгледът ще се покаже там
Сега искам да реализирам подмаршрути и мързеливо зареждане на модули на тази основа.
RouterModule.forRoot() и RouterModule.forChild()
Обектът RouterModule предоставя два статични метода: forRoot() и forChild() за конфигуриране на маршрутизиращата информация.
Методът RouterModule.forRoot() се използва за дефиниране на основната маршрутизираща информация в основния модул, а RouterModule.forChild() е подобен на метода Router.forRoot(), но може да се прилага само в функционални модули.
Тоест, forRoot() се използва в кореновия модул, а forChild() се използва в подмодула.
Синът му Лу Жу
Да предположим, че има две страници под страницата /settings settings, /settings/profile и /settings/password, които представляват страницата с профила и страницата за смяна на паролата съответно. поставя се като отделен функционален блок, който може да бъде капсулиран в модул на функции. Той има свои собствени независими маршрути, а маршрутите за страниците с профили и пароли могат да бъдат зададени като подмаршрути.
В модула SettingsModule използваме метода forChild(), тъй като SettingsModule не е основният модул на нашето приложение.
Друга голяма разлика е, че зададохме основния път на модула SettingsModule на празен път (''). Защото ако зададем пътя към /settings, ще съвпадне с /settings/settings. Като се задава празен път, той съвпада с пътя /settings.
Мързеливо зареждане: loadChildren
Конфигурирайте маршрутизиращата информация на модула за настройка в основния модул AppModule:
Тук се използва свойството LoadChildren за мързеливо зареждане. Вместо да импортира SettingsModule в AppModule, свойството loadChildren казва на Angular маршрута да зареди модула SettingsModule според пътя, конфигуриран от loadChildren свойството. Това е специфичното приложение на функцията за мързеливо зареждане на модула – когато потребителят достъпи пътя /settings/**, съответният модул SettingsModule ще бъде зареден, което намалява размера на натоварения ресурс при стартиране на приложението.
loadСтойността на свойството на децата се състои от три части:
Необходими са относителни пътища към импортните модули
#分隔符
Експортирайте името на класа модули
Модул CommonModule
Споменах, че искам да въведа модула CommonModule в модула за функции, но първоначално не забелязах, че искам да го въведа в модула за функции, и в резултат грешката на страницата беше докладвана по време на маршрутизирането:
core.es5.js:1020 ERROR Error: Uncaught (in promise): Error: Template parse errors:
Не мога да се свържа с 'ngClass', тъй като това не е известно свойство на 'div'.
Не мога да се свържа с 'ngForOf', тъй като не е известно свойство на 'p'.
Property binding ngForOf не се използва от никаква директива върху вграден шаблон. Уверете се, че името на имота е изписано правилно и всички указания са изброени в "@NgModule.декларации".
Не мога да се свържа с 'ngIf', тъй като това не е известно свойство на 'div'.
......
След дълго наблюдение установих, че причината е, че не съм въвел CommonModule в модула с функции, и след като го въведох, тези грешки изчезнаха.
CommonModule предоставя много често използвани инструкции в приложения, включително NgIf и NgFor. По-точно, директиви като Ngif се декларират в CommonModule от @angular/common.
Импортирахме модула BrowserModule в коренния модул AppModule, който импортира CommonModule и го експортира отново. Крайният резултат е, че докато импортирате BrowserModule, автоматично ще получавате инструкциите в CommonModule.
Импортирането на BrowserModule прави всички компоненти, директиви и конвейери, изложени от модула, достъпни директно във всеки компонентен шаблон под AppModule, без допълнителни досадни стъпки. Но не импортирайте BrowserModule в друг модул. Функционални модули и модули за мързеливо зареждане трябва да се импортират в CommonModule. Те не изискват повторна инициализация на целия доставчик на приложение на ниво. Ако импортирате BrowserModule в мързелив модул за зареждане, Angular издава грешка.
Това са някои от проблемите и обобщенията, с които се сблъсках през последните два дни, използвайки ъглови подлинии и мързеливо зареждане.
|
Публикувано в 13.06.2019 г. 13:13:10 ч.
|
|
|
|
