The base class for route guards, and the context they receive.
Why a guard has a context
A guard used to receive nothing. It answered canActivate(to, from) from the
route alone, and anything else it needed had to be reached through whatever
happened to be in lexical scope. For a guard compiled into the application
bundle that was an accident of concatenation, and when the compiler stopped
emitting a binding the guard's identifier silently became undefined.
That left the ordinary case unwritable. "Is this visitor signed in?" is the
reason route guards exist, and the answer lives in a bridge — which a guard
had no supported way to read: it received no injection, and the template
sandbox refuses window. The only decisions a guard could make were the ones
the URL already carried.
The context makes that dependency explicit rather than lexical. A guard is handed the framework-level capabilities it is allowed to use, by the router that invoked it, at the moment it runs.
What the context deliberately does not carry
Browser globals. The context exposes the application's bridges and the
router that is asking; it is not an escape hatch to document,
localStorage or fetch. A guard that genuinely needs a browser API should
read it through a bridge, which is the same rule the rest of the framework
follows and the reason a bridge read is traceable at all.
- Source: