This option has already been removed from availability externally. Internally, the last use has been removed
for the type on Route.loadChildren. More testing will be necessary to verify nothing relies on the other
code paths.
PR Close#48292
The navigationId is really just a count of how many navigations have been
processed through the navigation pipeline. This tracking should be
done as part of the navigation transition handler
PR Close#48202
Rather than accessing router internal properties that are available in DI,
this commit directly injects those dependencies in the navigation transition
handler. Note that there are several other items that _should_ be injectable
in DI (like the TitleStrategy) but because those are part of the Router public
interface and writeable(!), they might be changed during runtime. We
have to get these other items from the Router for now...
PR Close#48202
Remove the NgModuleRef from the internal interface of the Router. This
was only used to get the injector (equivalent to EnvironmentInjector).
Instead, the navigation transition handler can directly inject the
EnvironmentInjector
PR Close#48202
The ConfigLoader is only used as part of the navigation transition.
Moving the loader there completes the removal of event triggering in
the router code. This all now lives in the transition handler (plus
the router scroller, but let's ignore that...).
PR Close#48202
The events observable is part of the lifecycle of a navigation. This should
be contained in the NavigationTransitions class rather than the Router.
This Subject is re-exported by the router as an observable to maintain
the public API
PR Close#48202
Move the copy of the bazel dist folder to the firebase dist folder
earlier on in the process so that any checks operate out of a single
folder.
PR Close#48265
Similar to the Rules NodeJS require patch, we have an ESM import patch
as of the AIO Bazel migration (to support ESM scripts better).
This script uses `--loader`, an experimental NodeJS flag. This is
similar to how `ts-node` uses it. We should disable the warnings
as it results in a lot of unreadable Bazel output and the warnings
are okay to be ignored. Note that we cannot fine-grain disable
the specific warning so all others would be disabled too.
Realistically we haven't seen any in the past and long-term we will
be not relying on patched resolution anyway (looking at `rules_js`).
PR Close#48282
The navigationId is really just a count of how many navigations have been
processed through the navigation pipeline. This tracking should be
done as part of the navigation transition handler
PR Close#48202
Rather than accessing router internal properties that are available in DI,
this commit directly injects those dependencies in the navigation transition
handler. Note that there are several other items that _should_ be injectable
in DI (like the TitleStrategy) but because those are part of the Router public
interface and writeable(!), they might be changed during runtime. We
have to get these other items from the Router for now...
PR Close#48202
Remove the NgModuleRef from the internal interface of the Router. This
was only used to get the injector (equivalent to EnvironmentInjector).
Instead, the navigation transition handler can directly inject the
EnvironmentInjector
PR Close#48202
The ConfigLoader is only used as part of the navigation transition.
Moving the loader there completes the removal of event triggering in
the router code. This all now lives in the transition handler (plus
the router scroller, but let's ignore that...).
PR Close#48202
The events observable is part of the lifecycle of a navigation. This should
be contained in the NavigationTransitions class rather than the Router.
This Subject is re-exported by the router as an observable to maintain
the public API
PR Close#48202
As mentioned in #46021, `canMatch` guards can replace `canLoad`. There
are slight differences between the two but the purpose of preventing
user access to feature modules is still achievable. There are several
reasons keeping `CanLoad` around is detrimental to the API surface:
* Lazy loading should not be an architectural feature of an application. It's an
optimization you do for code size. That is, there should not be an architectural
feature in the router to directly specifically control whether to lazy load something or
not based on conditions such as authentication. This slightly
different from the `canMatch` guard: the guard controls whether
you can use the route at all and as a side-effect, whether we download the code.
`CanLoad` only specified whether the code should be downloaded so `canMatch` is
more powerful and more appropriate.
* The naming of `CanLoad` will be potentially misunderstood for the `loadComponent` feature.
Because it applies to `loadChildren`, it feels reasonable to think that it will
also apply to `loadComponent`. This isn’t the case: since we don't need
to load the component until right before activation, we defer the
loading until all guards/resolvers have run.
* Unnecessary API surface bloat where two features (CanMatch and CanLoad) do
essentially the same thing. This affects code size for supporting two
nearly identical features as well as the learning and teaching journey
for them both.
* `CanLoad` guards have the downside of _only_ being run once to prevent
loading child routes. Once that passes and children are loaded, the
guard never runs again. As a result, developers need to always provide
_both_ canLoad and a canActivate in case the answer to the guard flips
back to `false`. This is not the case for `canMatch`, which will run
on every navigation.
DEPRECATED: CanLoad guards in the Router are deprecated. Use CanMatch
instead.
PR Close#48180
Prior to the AIO bazel migration, the pwa test script only tested the
pwa metric. A bug was introduced where the score target was used for all
metrics, causing the AIO deploy test to fail.
The stricter checks under `strictInjectionParameters` in Angular 15 now enforce that
an inherited constructor must be compatible with DI, based on whether all parameters
are valid injection tokens. There is an issue when the constructor is inherited from
a class in a declaration file though, as information on the usage of `@Inject()` is
not present within a declaration file. This means that this stricter check cannot be
accurately performed, resulting in false positives.
This commit disables the stricter check to behave the same as it did prior to
Angular 15, therefore avoiding the false positive.
Fixes#48152
PR Close#48156
