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.