Preloading Lazy-Loaded Feature Modules In Angular 6.1.9

import { PreloadAllModules } from "@angular/router";
import { RouterModule } from "@angular/router";

// .... [truncated]

RouterModule.forRoot(
	// ....
	{
		// Tell the router to use the HashLocationStrategy.
		useHash: true,
		enableTracing: false,

		// This will tell Angular to preload the lazy-loaded routes after the
		// application has been bootstrapped. This will extend to both top-level
		// and nested lazy-loaded modules.
		preloadingStrategy: PreloadAllModules
	}
)

// Import the core angular services.
import { Component } from "@angular/core";
import { Event as RouterEvent } from "@angular/router";
import { NavigationCancel } from "@angular/router";
import { NavigationEnd } from "@angular/router";
import { NavigationError } from "@angular/router";
import { NavigationStart } from "@angular/router";
import { Router } from "@angular/router";
import { RouteConfigLoadEnd } from "@angular/router";
import { RouteConfigLoadStart } from "@angular/router";

// ----------------------------------------------------------------------------------- //
// ----------------------------------------------------------------------------------- //

@Component({
	selector: "my-app",
	styleUrls: [ "./app-view.component.less" ],
	templateUrl: "./app-view.component.htm"
})
export class AppViewComponent {

	public isShowingRouteLoadIndicator: boolean;

	// I initialize the app view component.
	constructor( router: Router ) {

		this.isShowingRouteLoadIndicator = false;

		// *************************************************************************** //
		// CAUTION: Even though we are preloading our lazy-loading modules with the
		// "PreloadAllModules" configuration, the following Router events still fire
		// when the RouterPreloader's requests for the remote code are initiated and
		// completed, respectively. As such, this code is still relevant. And, on a
		// slower connection, may still show the loading indicator shortly after the
		// application has been bootstrapped (depending on what the initial URL of
		// the application is).
		// *************************************************************************** //

		// As the router loads modules asynchronously (via loadChildren), we're going to
		// keep track of how many asynchronous requests are currently active. If there is
		// at least one pending load request, we'll show the indicator.
		var asyncLoadCount = 0;

		// As the user navigates around the application, we're going to keep track of how
		// many pending navigation requests are currently active. This way, we can know
		// if the asynchronous module loading is [possibly] happening because of a user
		// navigation; or, if it's happening as part of the pre-loading.
		var navigationCount = 0;

		// The Router emits special events for "loadChildren" configuration loading. We
		// just need to listen for the Start and End events, amidst the rest of the
		// events, in order to determine if we have any pending configuration requests.
		router.events.subscribe(
			( event: RouterEvent ) : void => {

				if ( event instanceof RouteConfigLoadStart ) {

					asyncLoadCount++;

				} else if ( event instanceof RouteConfigLoadEnd ) {

					asyncLoadCount--;

				} else if ( event instanceof NavigationStart ) {

					navigationCount++;

				} else if (
					( event instanceof NavigationEnd ) ||
					( event instanceof NavigationError ) ||
					( event instanceof NavigationCancel )
					) {

					navigationCount--;

				}

				// If there is at least one pending asynchronous config load request AND
				// it is taking place while a the user is actively navigating around the
				// application, then let's show the loading indicator. This way, we don't
				// show the loading indicator during the preloading of lazy modules. This
				// isn't an exact science, since the navigation may not be tied to the
				// config load request. But, the small delay in rendering the indicator
				// should make the fuzzy-association a non-issue (as unrelated navigation
				// events will start and end almost instantly).
				// --
				// CAUTION: I'm using CSS to include a small delay such that this loading
				// indicator won't be seen by people with sufficiently fast connections.
				this.isShowingRouteLoadIndicator = !! ( navigationCount && asyncLoadCount );

			}
		);

	}

}

App View

<p>
	<a routerLink="/app/">Home</a> &mdash;
	<a routerLink="/app/feature-a">Feature A</a> &mdash;
	<a routerLink="/app/feature-b">Feature B</a> &mdash;
	<a routerLink="/app/feature-c">Feature C</a> &mdash;
	<a [routerLink]="[ '/app', { outlets: { aside: 'aside' } } ]">Aside</a>
</p>

<router-outlet></router-outlet>

<router-outlet name="aside"></router-outlet>

<!-- I indicate that a router module is being loaded asynchronously. -->
<div
	*ngIf="isShowingRouteLoadIndicator"
	class="router-load-indicator">
	Loading Module
</div>

:host {
	display: block ;
}

a {
	color: red ;
	cursor: pointer ;
	text-decoration: underline ;
}

// On a fast network connection, the lazy-loaded modules will load almost instantly. In
// such a case, we don't want to bother showing the asynchronous loading indicator as it
// will simply flash the UI and create a distracting user experience. As such, we want to
// put a small delay on the "observability" of the loading indicator. This way, on a fast
// connection, it will be removed before the delay is consumed; and, on a slower network
// connection, it will be shown to the user soon after the asynchronous load starts.
// --
// CAUTION: keyframes are not "protected" by Angular's simulated encapsulation. As such,
// this animation name needs to be universally unique to the application.
@keyframes router-load-indicator-animation {
	from {
		opacity: 0.0 ;
	}

	to {
		opacity: 1.0 ;
	}
}

.router-load-indicator {
	// Delay the animation for a fast network connection (so users don't see the loader).
	animation-delay: 100ms ;
	animation-duration: 200ms ;
	animation-fill-mode: both ;
	animation-name: router-load-indicator-animation ;
	// --
	background-color: #ffdc73 ;
	border-radius: 5px 5px 5px 5px ;
	box-shadow: 0px 2px 2px fade( #000000, 20% ) ;
	color: #000000 ;
	font-family: monospace ;
	font-size: 16px ;
	left: 50% ;
	padding: 7px 15px 7px 15px ;
	position: fixed ;
	text-transform: lowercase ;
	top: 10px ;
	transform: translateX( -50% ) ;
	z-index: 2 ;
}

// Import the core angular services.
// import { BrowserAnimationsModule } from "@angular/platform-browser/animations";
import { BrowserModule } from "@angular/platform-browser";
import { NgModule } from "@angular/core";
import { PreloadAllModules } from "@angular/router";
import { RouterModule } from "@angular/router";
import { Routes } from "@angular/router";

// Import the application components and services.
import { AppViewComponent } from "./views/app-view.component";
import { AsideView } from "./views/aside-view/aside-view.module";
import { FeatureAView } from "./views/feature-a-view/feature-a-view.module";
import { FeatureBView } from "./views/feature-b-view/feature-b-view.module";
import { FeatureCView } from "./views/feature-c-view/feature-c-view.module";

// ----------------------------------------------------------------------------------- //
// ----------------------------------------------------------------------------------- //

// When we included a routable view into the router tree, we have to define the routes
// and, SOMETIMES, import the view modules (when statically loaded). In order to keep
// the routing semantics consistent across our views, I'm pushing both the ROUTE and
// MODULE definitions into the subview. This way, the parent context always SPREADS both
// the modules (into the imports) and the routes (into the RouterModule) into its own
// definition. This allows a module to switch from statically loaded to lazy loaded
// without the parent context having to know about it.
export interface RoutableView {
	modules: any[],
	routes: Routes
}

@NgModule({
	imports: [
		BrowserModule,
		// NOTE: When a routing module is statically included, then the routing module
		// needs to be explicitly imported. In order to not worry about this divergence,
		// let's let the child module define the importable modules (which may or may
		// not be an EMPTY ARRAY - empty if lazy-loaded).
		// --
		...AsideView.modules, // <--- empty array.
		...FeatureAView.modules, // <--- empty array.
		...FeatureBView.modules, // <--- empty array.
		...FeatureCView.modules,
		// --
		RouterModule.forRoot(
			[
				{
					path: "app",
					children: [
						// CAUTION: These routes define LAZY LOADED modules.
						...FeatureAView.routes, // <--- using "loadChildren"
						...FeatureBView.routes, // <--- using "loadChildren"
						...AsideView.routes, // <--- using "loadChildren"

						// CAUTION: These routes define STATICALLY LOADED modules.
						...FeatureCView.routes
					]
				},
				// Handle root redirect to app.
				{
					path: "",
					pathMatch: "full",
					redirectTo: "app"
				},
				// Handle root not-found redirect.
				{
					path: "**",
					redirectTo: "/app"
				}
			],
			{
				// Tell the router to use the HashLocationStrategy.
				useHash: true,
				enableTracing: false,

				// This will tell Angular to preload the lazy-loaded routes after the
				// application has been bootstrapped. This will extend to both top-level
				// and nested lazy-loaded modules.
				preloadingStrategy: PreloadAllModules
			}
		)
	],
	providers: [
		// CAUTION: We don't need to specify the LocationStrategy because we are setting
		// the "useHash" property in the Router module above (which will be setting the
		// strategy for us).
		// --
		// {
		// provide: LocationStrategy,
		// useClass: HashLocationStrategy
		// }
	],
	declarations: [
		AppViewComponent
	],
	bootstrap: [
		AppViewComponent
	]
})
export class AppModule {
	// ...
}