Angular's route loading is considerably optimized through its AoT template generation. However, you can actually tune and refine Angular's router preloading options through some configuration options in your router. These options are most interesting when you are optimizing your web application for mobile contexts where your application's load performance has a very high impact on your application's user experience.
Route preloading with Angular modules
Getting ready
Let's make our posts module a lazy loading module so that our application will start more quickly. We'll pair that module loading behavior with Angular's module preloading capability so that our app will still launch quickly, but will also load the posts module in the background after the application has started up without waiting for the user to navigate to /posts.
How to do it...
- To take advantage of route preloading, we first have to turn it on in our root router configuration. By default, the Angular router comes with one of two preloading strategies; preload everything with PreloadAllModules, or preload nothing with NoPreloading:
...
import {RouterModule, PreloadAllModules} from '@angular/router';
@NgModule({
...
imports: [
BrowserModule,
FormsModule,
HttpModule,
RouterModule.forRoot(ROUTES, { preloadingStrategy: PreloadAllModules })
],
...
})
export class AppModule { }
- Now that we have enabled preloading on our root router configuration, we have to enable lazy loading modules. For our router configuration, we must provide our lazy loaded child module in a string format using the loadChildren property. We also must provide the name of the module class itself to be invoked by the preloading strategy:
...
const ROUTES = [{
path: "posts"
loadChildren: "posts/posts.module#postModule"
}];
...
- With this configuration in place, the application will automatically start preloading this posts, lazy loading module after it initially bootstraps the Angular application.
How it works...
The point of lazy loading is that it delays the startup cost associated with loading a module until the application makes a specific call to load it. This lowers the overall start up cost of the application, but the potential downside is that the module will be a bit slower to get started when the user attempts to access it. By pairing this with a preloading strategy, we are actually having our cake and eating it too by asking Angular to preload the lazy loading module after startup, but before the user would potentially fetch the module.
