Route guards (canActivate, canDeactivate) in Angular - Deep Dive

Overview - Route guards (canActivate, canDeactivate)

What is it?

Route guards in Angular are special tools that control if a user can enter or leave a page. The canActivate guard checks if navigation to a page is allowed, while canDeactivate checks if leaving a page is okay. They help protect pages from unauthorized access or accidental data loss. This makes your app safer and friendlier.

Why it matters

Without route guards, users could access pages they shouldn't see or leave pages with unsaved changes, causing confusion or data loss. Route guards solve this by adding checkpoints before entering or leaving pages. This improves security and user experience, making apps feel reliable and professional.

Where it fits

Before learning route guards, you should understand Angular routing basics and components. After mastering guards, you can explore advanced routing features like lazy loading and resolver guards. Route guards fit in the journey after routing setup but before complex navigation control.

Mental Model

Core Idea

Route guards act like gatekeepers that decide if you can enter or leave a page based on rules.

Think of it like...

Imagine a museum with security guards at the doors. The canActivate guard is like the guard checking your ticket before you enter. The canDeactivate guard is like the guard asking if you want to take your belongings before you leave, preventing you from forgetting something important.

┌───────────────┐       ┌───────────────┐
│ User tries to │──────▶│ canActivate?  │
│ enter page    │       └──────┬────────┘
└───────────────┘              │ Yes/No
                               │
                               ▼
                      ┌─────────────────┐
                      │ Page loads if   │
                      │ allowed         │
                      └─────────────────┘

When leaving:

┌───────────────┐       ┌───────────────┐
│ User tries to │──────▶│ canDeactivate?│
│ leave page    │       └──────┬────────┘
└───────────────┘              │ Yes/No
                               │
                               ▼
                      ┌─────────────────┐
                      │ Navigation      │
                      │ proceeds if yes │
                      └─────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Angular Routing Basics

Concept: Learn how Angular routes connect URLs to components.

Angular routing lets you define paths that show different pages (components) when users visit URLs. You set up routes in a routing module, linking paths to components. For example, '/home' shows HomeComponent. This is the base for adding guards.

Result

You can navigate between pages using URLs, and Angular loads the right component.

Knowing routing basics is essential because guards control navigation decisions on these routes.

2

Foundation

What Are Route Guards in Angular

Concept: Route guards are interfaces that let you control navigation.

Angular provides interfaces like canActivate and canDeactivate. You create classes implementing these interfaces to add logic that runs before navigation. For example, canActivate returns true or false to allow or block entering a page.

Result

You can write code that stops or allows navigation based on conditions.

Understanding that guards are just code hooks before navigation helps you see their power and flexibility.

3

Intermediate

Implementing canActivate Guard

🤔Before reading on: do you think canActivate runs before or after the page loads? Commit to your answer.

Concept: canActivate runs before loading a route to decide if navigation is allowed.

Create a service implementing CanActivate interface with a method canActivate(). This method returns true to allow or false to block navigation. You add this guard to route config under 'canActivate'. For example, check if user is logged in before entering dashboard.

Result

Navigation to guarded routes only happens if canActivate returns true.

Knowing canActivate runs before loading prevents wasted loading and protects sensitive pages early.

4

Intermediate

Implementing canDeactivate Guard

🤔Before reading on: do you think canDeactivate runs when entering or leaving a page? Commit to your answer.

Concept: canDeactivate runs when leaving a route to confirm if navigation should proceed.

Create a service implementing CanDeactivate interface with a method canDeactivate(component). This method can check if the component has unsaved changes and ask the user to confirm leaving. Add this guard to route config under 'canDeactivate'.

Result

Users get warned or blocked from leaving pages with unsaved data.

Understanding canDeactivate helps prevent accidental data loss by intercepting navigation away.

5

Intermediate

Using Guards with Async Checks

🤔Before reading on: can guards handle asynchronous checks like server calls? Commit to your answer.

Concept: Guards can return promises or observables to handle async decisions.

canActivate and canDeactivate methods can return boolean, Promise, or Observable. This lets you check permissions from a server or show dialogs before allowing navigation. Angular waits for the async result before proceeding.

Result

Navigation waits for async checks, enabling dynamic and real-time guard decisions.

Knowing guards support async lets you build real-world checks like login status or confirmation dialogs.

6

Advanced

Combining Multiple Guards on Routes

🤔Before reading on: do multiple guards run in parallel or sequence? Commit to your answer.

Concept: Multiple guards on a route run in sequence, all must allow navigation.

You can add arrays of guards to canActivate or canDeactivate. Angular runs them one by one in order. If any guard returns false, navigation stops. This lets you layer checks, like authentication then role verification.

Result

Navigation only proceeds if all guards agree, enabling complex access control.

Understanding guard sequencing helps design layered security and user flow control.

7

Expert

Guard Internals and Change Detection Impact

🤔Before reading on: do guards trigger Angular change detection or component lifecycle hooks? Commit to your answer.

Concept: Guards run before component creation and do not trigger change detection or lifecycle hooks.

canActivate runs before the component is created, so no lifecycle hooks run if navigation is blocked. canDeactivate runs on the existing component instance before destruction. Guards run outside Angular's change detection cycle, so side effects must be handled carefully.

Result

You avoid unnecessary component loading and understand when component code runs relative to guards.

Knowing guard timing prevents bugs from assuming component state exists during guard checks.

Under the Hood

Angular routing uses a navigation pipeline. When navigation starts, it checks all guards in order. canDeactivate guards run on the current component before destroying it. canActivate guards run before creating the target component. If any returns false or a rejected promise, navigation cancels. Angular waits for all guards to resolve before proceeding. This pipeline ensures controlled, predictable navigation.

Why designed this way?

This design separates navigation control from component logic, improving modularity and security. Running canActivate before component creation saves resources by not loading unauthorized pages. canDeactivate protects user data by intercepting navigation away. Alternatives like inline checks in components would mix concerns and reduce reusability.

Navigation Start
    │
    ▼
┌───────────────┐
│ canDeactivate │ (on current component)
└──────┬────────┘
       │ Yes/No
       ▼
┌───────────────┐
│ canActivate   │ (before new component)
└──────┬────────┘
       │ Yes/No
       ▼
┌───────────────┐
│ Load Component│
└───────────────┘
       │
       ▼
┌───────────────┐
│ Navigation    │
│ Complete      │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does canActivate run after the component loads? Commit to yes or no.

Common Belief: canActivate runs after the component loads and can block rendering.

Reality: canActivate runs before the component is created, so it blocks navigation early.

Why it matters: Believing it runs after loading leads to wasted resources and unexpected UI flashes.

Quick: Can canDeactivate guard prevent navigation without user confirmation? Commit to yes or no.

Common Belief: canDeactivate only warns users but cannot block navigation.

Reality: canDeactivate can fully block navigation by returning false, not just warn.

Why it matters: Thinking it only warns causes developers to miss opportunities to protect data.

Quick: Do multiple guards on a route run simultaneously? Commit to yes or no.

Common Belief: All guards run at the same time, so order does not matter.

Reality: Guards run in sequence, and order affects navigation outcome.

Why it matters: Ignoring order can cause unexpected navigation behavior and security holes.

Quick: Can guards access component properties during canActivate? Commit to yes or no.

Common Belief: canActivate can access the component instance and its properties.

Reality: canActivate runs before component creation, so no component instance exists yet.

Why it matters: Trying to access component data in canActivate causes runtime errors.

Expert Zone

1

Guards can return UrlTree objects to redirect navigation instead of just true/false, enabling smooth reroutes.

2

Using guards with lazy-loaded modules requires careful placement to avoid redundant checks and improve performance.

3

canDeactivate guards can be used not only for unsaved changes but also to confirm destructive actions or cleanup tasks.

When NOT to use

Avoid using route guards for UI state changes or minor validations better handled inside components. For complex authorization, consider server-side checks or token-based guards. For data fetching, use resolvers instead of guards.

Production Patterns

In real apps, canActivate guards often check authentication and roles, while canDeactivate guards protect forms with unsaved changes. Guards are combined with lazy loading to secure feature modules. Redirecting unauthorized users to login pages using UrlTree is a common pattern.

Connections

Middleware in Web Servers

Route guards act like middleware that intercept requests before reaching handlers.

Understanding middleware helps grasp how guards control flow and enforce rules before processing.

Access Control Lists (ACL) in Security

Guards implement access control by allowing or denying navigation similar to ACL permissions.

Knowing ACL concepts clarifies how guards enforce security policies in apps.

Human Decision-Making Processes

Guards mimic how people decide to enter or leave situations based on conditions and risks.

Recognizing this connection helps design intuitive guard logic that matches user expectations.

Common Pitfalls

#1 Trying to access component data inside canActivate guard.

Wrong approach:

canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot) {
return this.component.someProperty === true;
}

Correct approach:

canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot) {
return this.authService.isLoggedIn();
}

Root cause:

Misunderstanding that canActivate runs before component creation, so component instance is not available.

#2 Not returning a value from canDeactivate, causing navigation to hang.

Wrong approach:

canDeactivate(component: SomeComponent) {
if (component.hasUnsavedChanges()) {
window.confirm('Leave?');
}
// Missing return statement
}

Correct approach:

canDeactivate(component: SomeComponent) {
if (component.hasUnsavedChanges()) {
return window.confirm('Leave?');
}
return true;
}

Root cause:

Forgetting that guards must return boolean or observable/promise to signal navigation decision.

#3 Adding guards to routes but forgetting to provide the guard service.

Wrong approach:

const routes = [
{ path: 'dashboard', component: DashboardComponent, canActivate: [AuthGuard] }
];
// AuthGuard not provided in module or root

Correct approach:

@Injectable({ providedIn: 'root' })
export class AuthGuard implements CanActivate { ... }

const routes = [
{ path: 'dashboard', component: DashboardComponent, canActivate: [AuthGuard] }
];

Root cause:

Not registering guard service causes Angular to fail injecting it, breaking navigation.

Key Takeaways

Route guards in Angular control navigation by allowing or blocking access to routes before entering or leaving.

canActivate runs before a route loads to check if navigation is allowed, while canDeactivate runs before leaving to confirm or block exit.

Guards can handle synchronous or asynchronous logic, enabling real-world checks like authentication or user confirmation dialogs.

Multiple guards run in sequence, and their order affects navigation decisions, allowing layered security.

Understanding guard timing and lifecycle prevents common mistakes like accessing component data too early or forgetting to return values.

Practice

1. What is the primary purpose of the canActivate guard in Angular routing?

easy

A. To handle errors during route navigation.

B. To check if navigation to a route is allowed before entering it.

C. To preload data before the route loads.

D. To confirm if navigation away from a route is allowed.

Solution

1. Step 1: Understand the role of canActivate

   canActivate is a route guard that runs before entering a route to decide if navigation is allowed.

2. Step 2: Differentiate from other guards

   canDeactivate checks leaving a route, not entering. Preloading and error handling are unrelated to canActivate.

3. Final Answer:

   To check if navigation to a route is allowed before entering it. -> Option B

4. Quick Check:

   canActivate = check before entering route [OK]

Hint: canActivate controls entering routes, canDeactivate controls leaving [OK]

Common Mistakes:

• Confusing canActivate with canDeactivate
• Thinking canActivate preloads data
• Assuming canActivate handles errors

2. Which of the following is the correct syntax to apply a canDeactivate guard to a route in Angular?

easy

A. { path: 'edit', component: EditComponent, canDeactivate: [UnsavedChangesGuard] }

B. { path: 'edit', component: EditComponent, canLoad: [LoadGuard] }

C. { path: 'edit', component: EditComponent, canActivate: [AuthGuard] }

D. { path: 'edit', component: EditComponent, canActivateChild: [ChildGuard] }

Solution

1. Step 1: Identify the guard type for leaving routes

   canDeactivate is used to check if navigation away from a route is allowed.

2. Step 2: Match syntax with canDeactivate

   The correct syntax uses canDeactivate: [GuardName] inside the route object.

3. Final Answer:

   { path: 'edit', component: EditComponent, canDeactivate: [UnsavedChangesGuard] } -> Option A

4. Quick Check:

   canDeactivate syntax = canDeactivate: [Guard] [OK]

Hint: Use canDeactivate: [Guard] to protect leaving a route [OK]

Common Mistakes:

• Using canActivate instead of canDeactivate for leaving routes
• Confusing canLoad with canDeactivate
• Missing brackets around guard name

3. Given this canDeactivate guard code snippet, what will happen when the user tries to leave the EditComponent with unsaved changes?

export class UnsavedChangesGuard implements CanDeactivate<EditComponent> {
  canDeactivate(component: EditComponent): boolean {
    if (component.hasUnsavedChanges()) {
      return confirm('You have unsaved changes. Leave anyway?');
    }
    return true;
  }
}

medium

A. The guard throws an error because confirm is not allowed.

B. The user is always allowed to leave without confirmation.

C. The user is blocked from leaving if there are unsaved changes.

D. The user is asked to confirm leaving only if there are unsaved changes.

Solution

1. Step 1: Analyze the guard logic

   The guard checks if component.hasUnsavedChanges() returns true, then asks for confirmation.

2. Step 2: Understand the confirm behavior

   If the user confirms, confirm() returns true allowing navigation; otherwise, navigation is blocked.

3. Final Answer:

   The user is asked to confirm leaving only if there are unsaved changes. -> Option D

4. Quick Check:

   canDeactivate confirms only if unsaved changes exist [OK]

Hint: canDeactivate can prompt user to confirm leaving [OK]

Common Mistakes:

• Assuming user can leave without confirmation always
• Thinking guard blocks leaving without prompt
• Believing confirm causes errors in Angular guards

4. Identify the error in this canActivate guard implementation:

export class AuthGuard implements CanActivate {
  canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot) {
    if (this.authService.isLoggedIn()) {
      return true;
    }
  }
}

medium

A. Missing return statement when user is not logged in.

B. Incorrect method name; should be canDeactivate.

C. The guard should return a Promise, not boolean.

D. The guard must not use services inside canActivate.

Solution

1. Step 1: Check all code paths return a value

   If isLoggedIn() is false, the method returns nothing (undefined), which is invalid.

2. Step 2: Understand guard return requirements

   canActivate must return true, false, or an observable/promise resolving to those. Missing return causes errors.

3. Final Answer:

   Missing return statement when user is not logged in. -> Option A

4. Quick Check:

   All canActivate paths must return true/false [OK]

Hint: Always return true or false in all canActivate paths [OK]

Common Mistakes:

• Not returning false or redirect when unauthorized
• Confusing canActivate with canDeactivate method names
• Thinking services can't be used in guards

5. You want to prevent users from leaving a form page if they have unsaved changes, but only if they are editing (not creating new). Which approach correctly uses canDeactivate to achieve this?

hard

A. Use canActivate guard to check unsaved changes before entering the form route.

B. Use canDeactivate guard that always returns true to allow navigation.

C. Use canDeactivate guard that checks component.isEditing and component.hasUnsavedChanges() before confirming navigation.

D. Use canActivateChild guard to block leaving the form.

Solution

1. Step 1: Identify when to block navigation away

   Blocking leaving only applies when editing and unsaved changes exist, so guard must check both conditions.

2. Step 2: Use canDeactivate guard properly

   canDeactivate runs when leaving a route, so it is the correct place to check and confirm navigation.

3. Final Answer:

   Use canDeactivate guard that checks component.isEditing and component.hasUnsavedChanges() before confirming navigation. -> Option C

4. Quick Check:

   canDeactivate with condition on editing and unsaved changes [OK]

Hint: Check editing and unsaved changes inside canDeactivate guard [OK]

Common Mistakes:

• Using canActivate to block leaving routes
• Always returning true in canDeactivate guard
• Confusing canActivateChild with canDeactivate