Guards: The Gatekeepers of Angular

Guards act as gatekeepers in Angular applications, determining access to specific routes based on established conditions. They are crucial for enforcing authentication, authorization, and various navigation rules, thus preventing unauthorized access or inappropriate route navigation.

Developers commonly use Guards to apply security measures, limit access to certain routes, or dictate navigation based on dynamic criteria. They are also useful for performing actions before accessing a route, such as verifying user credentials or permissions.

CanActivate vs. CanActivateFn

Historically, Guards were implemented using the CanActivate interface, which required strict adherence to a specific method structure. This often led to verbose and less readable code, increasing complexity.

The introduction of CanActivateFn offers a more concise alternative. By utilizing a function-based approach, developers can express Guard logic more clearly, improving code readability and maintainability. This transition simplifies the implementation process, reducing boilerplate code and the likelihood of errors.

Pros and Cons of CanActivateFn

The shift from CanActivate to CanActivateFn brings several benefits:

• Enhanced Readability: CanActivateFn fosters cleaner and more compact code, making it easier to understand and maintain.
• Less Boilerplate: By removing the need for class-based implementations, CanActivateFn streamlines development by minimizing boilerplate code.
• Increased Flexibility: CanActivateFn allows developers to utilize functional programming techniques more effectively.

However, there are some potential downsides:

• Learning Curve: Developers familiar with the traditional CanActivate interface may need time to adjust to the new functional approach.
• Compatibility Issues: While CanActivateFn offers a more elegant solution, it may not align well with older codebases that heavily depend on the CanActivate interface.

Example: Implementing CanActivate

@Injectable({

providedIn: 'root'

})

export class AuthGuard implements CanActivate {

constructor(private authService: AuthService, private router: Router) {}

canActivate(

route: ActivatedRouteSnapshot,

state: RouterStateSnapshot

): Observable | Promise | boolean | UrlTree {

const isLoggedIn = this.authService.isLoggedIn();

const redirectToLogin = this.router.createUrlTree(['/login']);

return isLoggedIn ? true : redirectToLogin;

}

}

Example: Implementing CanActivateFn

// Reduced boilerplate code

export const AuthGuard: CanActivateFn = (

route: ActivatedRouteSnapshot,

state: RouterStateSnapshot

): Observable | Promise | boolean | UrlTree => {

const isLoggedIn = inject(AuthService).isLoggedIn();

const redirectToLogin = inject(Router).createUrlTree(['/login']);

return isLoggedIn ? true : redirectToLogin;

};

The above example leverages dependency injection to access services like AuthService and Router, simplifying the code and allowing for straightforward comprehension of the guard logic.

Role-Based Access Control (RBAC)

In addition to adopting CanActivateFn, implementing role-based access control (RBAC) through distinct guards significantly enhances route security within Angular applications. By creating separate guards for different user roles—such as CustomerAuthGuard, EmployeeAuthGuard, and AdminAuthGuard—developers can enforce precise access control tailored to each user role.

Example Implementation of CustomerAuthGuard:

export const CustomerAuthGuard: CanActivateFn = (

route: ActivatedRouteSnapshot,

state: RouterStateSnapshot

): Observable | Promise | boolean | UrlTree => {

const isLoggedIn = inject(AuthService).isLoggedIn();

const redirectToLogin = inject(Router).createUrlTree(['/login']);

// Validate if the user is a customer

// Implement role-specific logic

return isLoggedIn ? true : redirectToLogin;

};

The same pattern can be applied to develop EmployeeAuthGuard and AdminAuthGuard with specific logic for each role.