Lazy loading routes and modules in Angular - Step-by-Step Execution

Concept Flow - Lazy loading routes and modules

App starts

↓

User navigates to route

↓

Check if module loaded?

Yes→Render component

No↓

Load module asynchronously

↓

Render component from loaded module

↓

User interacts with app

The app waits to load a module until the user navigates to its route, then loads it asynchronously and renders its components.

Execution Sample

Angular

const routes = [
  { path: 'home', component: HomeComponent },
  { path: 'admin', loadChildren: () => import('./admin/admin.module').then(m => m.AdminModule) }
];

Defines routes where 'admin' module is loaded only when user visits '/admin' path.

Execution Table

Step	User Action	Module Loaded?	Action Taken	Result
1	App starts, user at '/'	No	Load root module only	HomeComponent ready
2	User clicks '/home'	Home module loaded	Render HomeComponent	HomeComponent visible
3	User clicks '/admin'	Admin module not loaded	Start loading AdminModule asynchronously	Loading spinner or blank screen
4	AdminModule loaded	Admin module loaded	Render AdminComponent from AdminModule	AdminComponent visible
5	User navigates away	Modules remain loaded	No unload by default	App continues running

💡 Lazy loading triggers only when user navigates to the route; modules load once and stay loaded.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
homeModuleLoaded	true	true	true	true	true
adminModuleLoaded	false	false	loading	true	true
currentComponent	HomeComponent	HomeComponent	loading screen	AdminComponent	AdminComponent

Key Moments - 3 Insights

Why doesn't the admin module load when the app starts?

Because lazy loading delays loading until the user navigates to the admin route, as shown in step 3 of the execution_table.

What happens if the user navigates back to '/home' after visiting '/admin'?

The home module is already loaded, so the app just renders HomeComponent without reloading modules, as seen in step 2 and step 5.

Does Angular unload lazy loaded modules when navigating away?

No, once loaded, modules stay in memory for faster navigation, as noted in step 5 of the execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of 'adminModuleLoaded' after step 3?

A "true"

B "loading"

C "false"

D "unloaded"

💡 Hint

Check the variable_tracker column 'After Step 3' for 'adminModuleLoaded'.

At which step does the admin module finish loading?

A Step 4

B Step 2

C Step 3

D Step 5

💡 Hint

Look at the 'Module Loaded?' column in execution_table for when admin module becomes loaded.

If the user never visits '/admin', what happens to the admin module?

A It loads at app start

B It loads after '/home'

C It never loads

D It loads when user clicks a button

💡 Hint

Refer to the concept_flow and execution_table steps 1 and 2 about lazy loading triggers.

Concept Snapshot

Lazy loading delays loading a module until its route is visited.
Use loadChildren with dynamic import in route config.
Modules load asynchronously, improving startup speed.
Once loaded, modules stay in memory.
Helps keep initial app bundle small and fast.

Full Transcript

Lazy loading in Angular means the app does not load all modules at startup. Instead, it waits until the user navigates to a route that needs a specific module. At that moment, Angular loads the module asynchronously. For example, the admin module only loads when the user visits '/admin'. This keeps the app fast initially. The execution table shows the app starting with only the root module loaded. When the user clicks '/admin', Angular starts loading the admin module. After loading, it renders the admin components. Modules stay loaded after first load for quick navigation. This technique improves app performance by reducing initial load size.

Practice

1. What is the main purpose of lazy loading modules in Angular?

easy

A. To preload all modules at application start for faster navigation

B. To load modules only when the user navigates to their routes, improving startup speed

C. To bundle all modules into a single large file

D. To disable routing in the application

Solution

1. Step 1: Understand lazy loading concept

   Lazy loading means loading parts of the app only when needed, not all at once.

2. Step 2: Identify benefit in Angular context

   Loading modules on demand speeds up the initial app load and reduces bundle size.

3. Final Answer:

   To load modules only when the user navigates to their routes, improving startup speed -> Option B

4. Quick Check:

   Lazy loading = load on demand [OK]

Hint: Lazy loading delays module load until route is visited [OK]

Common Mistakes:

• Thinking lazy loading loads all modules upfront
• Confusing lazy loading with preloading
• Assuming lazy loading disables routing

2. Which of the following is the correct syntax to lazy load a module in Angular routing?

easy

A. { path: 'admin', loadChildren: () => import('./admin/admin.module').then(m => m.AdminModule) }

B. { path: 'admin', loadChildren: './admin/admin.module#AdminModule' }

C. { path: 'admin', component: AdminModule }

D. { path: 'admin', loadModule: () => import('./admin/admin.module') }

Solution

1. Step 1: Recall Angular lazy loading syntax

   Angular uses dynamic import with loadChildren returning a promise resolving to the module.

2. Step 2: Match syntax to options

   { path: 'admin', loadChildren: () => import('./admin/admin.module').then(m => m.AdminModule) } uses the correct arrow function with dynamic import and then to get the module class.

3. Final Answer:

   { path: 'admin', loadChildren: () => import('./admin/admin.module').then(m => m.AdminModule) } -> Option A

4. Quick Check:

   Dynamic import + loadChildren = { path: 'admin', loadChildren: () => import('./admin/admin.module').then(m => m.AdminModule) } [OK]

Hint: Use arrow function with import().then() for lazy loading [OK]

Common Mistakes:

• Using deprecated string syntax for loadChildren
• Confusing component with module in route config
• Using wrong property name like loadModule

3. Given this route configuration snippet, what happens when the user navigates to '/dashboard'?

{ path: 'dashboard', loadChildren: () => import('./dashboard/dashboard.module').then(m => m.DashboardModule) }

medium

A. The DashboardModule is loaded immediately when the app starts

B. The app throws a runtime error due to incorrect syntax

C. The DashboardModule is never loaded

D. The DashboardModule is loaded only when the user navigates to '/dashboard'

Solution

1. Step 1: Analyze the route config with loadChildren

   The route uses lazy loading with a dynamic import function for DashboardModule.

2. Step 2: Understand lazy loading behavior on navigation

   The module loads only when the user visits '/dashboard', not before.

3. Final Answer:

   The DashboardModule is loaded only when the user navigates to '/dashboard' -> Option D

4. Quick Check:

   Lazy loading triggers on route visit [OK]

Hint: Lazy loaded modules load on first route access, not app start [OK]

Common Mistakes:

• Assuming module loads at app start
• Confusing lazy loading with eager loading
• Thinking syntax causes runtime error

4. Identify the error in this Angular route configuration for lazy loading:

{ path: 'profile', loadChildren: './profile/profile.module#ProfileModule' }

medium

A. The string syntax for loadChildren is deprecated and causes errors in Angular 17+

B. The path property should be named routePath

C. The module path should not include './' prefix

D. loadChildren should be replaced with loadModule

Solution

1. Step 1: Check loadChildren syntax

   The string syntax with '#' is deprecated in modern Angular versions (17+).

2. Step 2: Identify correct syntax

   Modern Angular requires dynamic import with arrow function for lazy loading.

3. Final Answer:

   The string syntax for loadChildren is deprecated and causes errors in Angular 17+ -> Option A

4. Quick Check:

   Deprecated string syntax = The string syntax for loadChildren is deprecated and causes errors in Angular 17+ [OK]

Hint: Use dynamic import syntax, not string with # [OK]

Common Mistakes:

• Using old string syntax for loadChildren
• Changing path property name incorrectly
• Replacing loadChildren with non-existent loadModule

5. You want to lazy load a feature module only if the user is authenticated. Which approach correctly combines lazy loading with route guarding in Angular?

hard

A. { path: 'settings', loadChildren: () => import('./settings/settings.module').then(m => m.SettingsModule), canActivate: [AuthGuard] }

B. { path: 'settings', component: SettingsComponent, canActivate: [AuthGuard] }

C. { path: 'settings', loadChildren: () => import('./settings/settings.module').then(m => m.SettingsModule), canLoad: [AuthGuard] }

D. { path: 'settings', loadChildren: './settings/settings.module#SettingsModule', canLoad: [AuthGuard] }

Solution

1. Step 1: Understand lazy loading with guards

   To prevent loading a module unless authorized, use canLoad guard with lazy loading.

2. Step 2: Analyze options for correct guard usage

   { path: 'settings', loadChildren: () => import('./settings/settings.module').then(m => m.SettingsModule), canLoad: [AuthGuard] } uses canLoad with dynamic import syntax, which is correct for lazy loaded modules.

3. Step 3: Explain why others are incorrect

   { path: 'settings', component: SettingsComponent, canActivate: [AuthGuard] } is eager loading with canActivate. { path: 'settings', loadChildren: () => import('./settings/settings.module').then(m => m.SettingsModule), canActivate: [AuthGuard] } uses canActivate which guards route activation but not module loading. { path: 'settings', loadChildren: './settings/settings.module#SettingsModule', canLoad: [AuthGuard] } uses deprecated string syntax.

4. Final Answer:

   { path: 'settings', loadChildren: () => import('./settings/settings.module').then(m => m.SettingsModule), canLoad: [AuthGuard] } -> Option C

5. Quick Check:

   Lazy load + canLoad guard = { path: 'settings', loadChildren: () => import('./settings/settings.module').then(m => m.SettingsModule), canLoad: [AuthGuard] } [OK]

Hint: Use canLoad guard with lazy loaded modules to block loading [OK]

Common Mistakes:

• Using canActivate instead of canLoad for lazy loading
• Using deprecated string syntax for loadChildren
• Applying guards on components instead of modules