Angular

318 readers

2 users here now

A community for discussion about angular

Wormhole

[email protected]

Logo base by Angular under CC BY 4.0 with modifications to add a gradient and drop shadow

founded 2 years ago

MODERATORS

Ategon

fabian

Help understanding canActivate vs canMatch guard (lemm.ee)

submitted 1 month ago by [email protected] to c/angular

4 comments fedilink hide all child comments

Im kind of new to Angular and I think I'm finally starting to understand the difference between canMatch and canActivate guards in terms of behavior, but I still struggle to understand which to use in which scenario.

Let's say I have an application with some component/page that requires a user to be logged in, and also have certain permissions. It seems to me that it doesn't really matter which one to use, right?

And yes, I understand that this is all client side and the actual backend endpoints need to do the same checks, I'm just wondering why you would use one over the other.

Any insights would be welcome.

Note: I'm using Angular 19.

you are viewing a single comment's thread
view the rest of the comments

[–] zlatko 2 points 6 days ago (3 children)

Hey all, I just spotted the question by accident. I'll try to answer it in case you're still wondering, or for some future concern.

The difference is that canMatch is being evaluated first, runs before you even look into the URL. Imagine that canMatch guard is only allowing admins in.

That means you can e.g. prevent even attempting to load the routes (e.g. lazily) if you know your current user is an admin. They try to open /site-settings or /users page or similar - and you just nope them back.

CanActivate, in contrast, will first go load the remote route, then try to match the user.

Now, you also asked why. Well, the difference is usually tiny, but it might make sense. Let's say you have some data loading, some actions being performed, some background sync operations running when you load a lazy route /admin. Example, you have /admin page, but when you load it, canActivate router needs to go back to server and ask if this particular admin can administer this particular tenant. If you use canActivate, some of these are running always. And if you know your user is not an admin at all, you don't even try to load the module, and you save that time.

Tiny bit of difference, but it can help sometime.

[–] [email protected] 1 points 6 days ago (2 children)

Thank you, that's actually the most clear answer i've come across. This gives me a follow up question, just to check if I understand correctly. Never trust the client asside, if an url blocked by canMatch, itwill not actually call the server then, right? Let's say I have a page /count, which if requested runs some code on the server that increments a counter. If /count is blocked by canMatch, it wont request the page, so the counter is not updated? While canActivate would actully request the page and update the counter. Is this right?

[–] zlatko 2 points 2 days ago (1 children)

Not that simple. You have several moving parts just in your frontend. But all of your frontend is still accessible. E.g. if you run ng build, the output javascript will contain links to your module:

/ src/app/app.routes.ts
var routes = [
  {
    path: "no-match",
    canMatch: [noMatchGuard],
    loadChildren: () => import("./chunk-2W7YI353.js").then((m) => m.NoMatchComponent)
  },
  {
    path: "no-activate",
    canActivate: [noActivateGuard],
    loadChildren: () => import("./chunk-JICQNUJU.js").then((m) => m.NoActivateComponent)
  }
];

So whoever wanted to see what's in those separate files and just load the code in those components directly.

And of course, you have the backend completely separately anyway. Those two lazy-loaded modules - whether protected by guards or not - will contain links to your /count. If they're called or not is not relevant, whoever is interested can read the code and find the URLs. Someone can just call your /count without even looking at your code.

See if this lil image of the moving parts helps:

[–] [email protected] 1 points 2 days ago

Thank you for taking the time to clear that up! Much appreciated!