It is not clear that when we provide a service to some eagerly loaded module of an application, then that service is available for components of all eagerly loaded modules of that application. It would be better to give a link for more information at least.
PR Close#47979
This commit prepares the documentation directories for future tutorials organized by directory.
Also, it moves the Angular Libraries topic from the Tutorials section to Developer Guides in TOC
PR Close#48162
Updates the angular.io landing page with new messaging
and new images. The Quick-start app has been updated
to demonstrate a minimalist Angular app and the value
proposition content has been updated.
PR Close#47047
AIO has two risk places where `node_modules` folders may exist and may
be accidentally picked up by Bazel- even though they are already added
as part of `.bazelignore` and made visible through `.gitignore`. It
doesn't hurt instructing Bazel to always ignore `node_modules` as part
of the `glob` instruction.
Co-authored-by: Joey Perrott <josephperrott@gmail.com>
PR Close#48329
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
Andrew Scott