Angular 2 lets developers forbid routes activation by means of a list of guards assigned to the canActivate property of a route definition.

{[ .route-def | =javascript= | 1.hl(2) ]}

Those guards are classes which implement the CanActivate interface, and the implementation can be a promise, for example when it entails a roundtrip to the server.

The way Angular 2 treats this list of guards is by applying .every(...) to the values of a merge-mapped list of observables.

{[ .check-guards | =javascript= | 1.hl(2) ]}

The list of guards is conceptually the same as a list of promises, and in fact all the guards could be promises because, as we see above, .from(...) is used to initialise check$.

Merge-mapping is exactly what we did in How to convert promises to an observable.

{[ .merge-map | =javascript= | 1.hl(2) ]}

If we now apply .every(...) to that merge-mapped list of promises, we can see how canActivate works for multiple guards.

{[ .every | =javascript= | 1.hl(2) ]}

Notice that the subscription is notified only once, as soon as the resolved promises make it clear what the result would be: the observable emits a false soon after getting the first false, or a true after getting all true-s. So, as expected, canActivate works as a short-circuit-ed AND of each guard of the list, according to the arrival order of values.

Also notice that the values of all the promises keep arriving as promises get resolved, even after the observable has completed. This means that guards intended to be used together in a list of guards should never have side effects (to avoid race conditions). If guard G1 had a side effect of activating route R1, and G2 had another for R2, then canActivate: [G1, G2] would unpredictably activate R1 or R2, depending on which guard completes later.