As demand increases, the functions of the project become more complex. At this time, you need to modularize the project and package components, instructions, and pipelines into cohesive functional blocks, which is just right to explore subroutes and lazy loading of modules in Angular4.
In the previous development, a simple routing function has been implemented in the root module, which can be summarized in the following three steps:
1、在app.module.ts文件中加载路由库，并且在@NgModule中引入RouterModule.forRoot方法，其中，appRoutes是路由数组，它定义了具体的路由规则。
2. Add a navigation bar to the shell component, where the routerLink command points to the destination of the route, and routerLinkActive adds css style to the selected label
3. Add a router-outlet command to the template of the shell component, and the view will be displayed there
Now I want to implement subroutes and lazy loading of modules on this basis.
RouterModule.forRoot() and RouterModule.forChild()
The RouterModule object provides two static methods: forRoot() and forChild() to configure the routing information.
The RouterModule.forRoot() method is used to define the main routing information in the main module, and RouterModule.forChild() is similar to the Router.forRoot() method, but it can only be applied in feature modules.
That is, forRoot() is used in the root module and forChild() is used in the submodule.
His son Lu Ru
Suppose there are two pages under our /settings settings page, /settings/profile and /settings/password, which represent the profile page and the password change page respectively. setting as a separate function block, which can be encapsulated into a feature module. It has its own independent routes, and the routes for the profile and password pages can be set as subroutes.
In the SettingsModule module we use the forChild() method, because SettingsModule is not the main module of our application.
Another major difference is that we set the main path of the SettingsModule module to an empty path (''). Because if we set the path to /settings, it will match /settings/settings. By specifying an empty path, it matches the /settings path.
Lazy loading: loadChildren
Configure the routing information of the setting module in the root module AppModule:
The lazy loading LoadChildren property is used here. Instead of importing the SettingsModule into the AppModule, the loadChildren property tells the Angular route to load the SettingsModule module according to the path configured by the loadChildren property. This is the specific application of the lazy loading function of the module, when the user accesses the /settings/** path, the corresponding SettingsModule module will be loaded, which reduces the size of the loaded resource when the application starts.
loadChildren's property value consists of three parts:
Relative paths to import modules are required
#分隔符
Export the name of the module class
CommonModule module
I mentioned that I wanted to introduce the CommonModule module in the feature module, but I didn't notice that I wanted to introduce it in the feature module at first, and as a result, the page error was reported during routing:
core.es5.js:1020 ERROR Error: Uncaught (in promise): Error: Template parse errors:
Can't bind to 'ngClass' since it isn't a known property of 'div'.
Can't bind to 'ngForOf' since it isn't a known property of 'p'.
Property binding ngForOf not used by any directive on an embedded template. Make sure that the property name is spelled correctly and all directives are listed in the "@NgModule.declarations".
Can't bind to 'ngIf' since it isn't a known property of 'div'.
......
After checking for a long time, I found that it was because I didn't introduce CommonModule in the feature module, and after introducing it, these errors disappeared.
CommonModule provides many commonly used instructions in applications, including NgIf and NgFor. More precisely, directives such as NgIf are declared in the CommonModule from @angular/common.
We imported the BrowserModule module in the root module AppModule, which imported the CommonModule and re-exported it. The end result is that as long as you import the BrowserModule, you will automatically get the instructions in the CommonModule.
Importing a BrowserModule makes all components, directives, and pipelines exposed by the module available directly in any component template under the AppModule without additional tedious steps. But don't import the BrowserModule into any other module. Feature modules and lazy loading modules should be imported into CommonModule instead. They do not require reinitializing the full application-level provider. If you import a BrowserModule in a lazy loading module, Angular throws an error.
These are some of the problems and summaries I have encountered in the past two days using Angular subroutes and lazy loading.
|
Posted on 6/13/2019 1:13:10 PM
|
|
|
|
