- update `errors.ts` to annotate the error NG0403, so that the runtime can add a link to that guide when an error is thrown
- update `application_ref_spec.ts` to include the new link of the error
- update `errors.md` as a result of running `yarn bazel test packages/core/test`
Fixes#47985
PR Close#48483
The `packages/localize` package still required some trickery
to support CommonJS because tests in the repo were running as CommonJS.
This commit removes the CommonJS logic in localize and its tests, so
that only ESM is used in production & tests.
PR Close#48521
`PlatformLocation` is already part of the public API so developers can
create their own. This means that developers would already be able to
access the existing `BrowserPlatformLocation` at runtime by injecting
it. The motivation for adding `BrowserPlatformLocation` to the public
API is because of those facts, but driven more by the fact that we are
looking to include `MockPlatformLocation` by default in TestBed.
Developers would need a way to revert back to the current behavior for
some tests that rely directly on browser interaction.
PR Close#48488
The argument against this feature:
Firstly, this isn't a navigation strategy that's very commonly desired.
Secondly, the hash strategy is a location configuration in `@angular/common`
and you can use it outside of the Router or with any custom router implementations.
So while the net effect of using the router is that it updates the URL which is
controlled by the strategy, this feature provider doesn't necessarily need to
exist in the Router. The location strategy is an application-wide configuration
and affects anything that imports `Location`. Of course, the Router does this
in a few places but plenty of other things might as well.
The argument for this feature:
* Discoverability. While `LocationStrategy` is technically in `@angular/common`, the most
common use-case _is_ when using it with the Router.
* Precedence in the `RouterModule.forRoot([], {useHash: true})`
* Precedence in other routing libraries (`createWebHashHistory` in VueJS
and `HashRouter` in React, for example)
* The implementation of `withHashLocation` is much more clear than
`useHash` was. You can look at the function and see that all it's
doing is adding the `HashLocationStrategy` to the providers list.
resolves#48295 / #47986
PR Close#48301
TestBed.overrideProvider should include `multi` support in its type. The
underlying implementation already supports it, as documented by the
tests which are currently casting the override to `any` to get around
the bad type.
PR Close#48424
This commit updates an internal `isStandalone` function and exposes it as a public API,
so that it can be used in applications code.
fixes#47919
PR Close#48114
The Router constructor and `setupRouter` factory mainly exist as a
legacy configuration. Since the Router's creation, the style in Angular
has evolved quite a bit. This commit eliminates and cleans up some
unnecessary comlicated code paths related to the router
constructor/factory.
Note that there are edits to the `setupTestingRouter` that could be seen
as breaking. However, it is not for several reasons:
1. The function is documented as a factory function. If used as
documented, the parameters should match what's available in DI
2. The function is totally unused by the Router itself and is not used
in g3 either. I believe it was made publicApi by an error when
updating documentation annotations long ago.
PR Close#48215
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 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
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
The router providers a configurable `onSameUrlNavigation` value that
allows developers to configure whether navigations to the same URL as
the current one should be processed or ignored. However, this only acts
as a default value and there isn't an API for easily overriding this for
a single navigation. Instead, developers are forced to update the value
of the property on the router instance and remember to reset it.
This feature fills a small gap in the Router APIs that enables
developers to accomplish the task of force reloading a bit easier.
Lengthy discussion about this here: #21115
PR Close#48050
This commit adds `TestBed.runInInjectionContext` which is equivalent to
`TestBed.inject(EnvironmentInjector).runInContext`. This function will
help make tests for functions which call `inject` from `@angular/core` a
little bit less verbose.
PR Close#47955
This commit extracts the Router's navigation "transitions" to a separate
file. The goal here is twofold:
- Separate the Router's logic into more manageable chunks. Rather than
having to always edit a 1000+ line file, this separates different
pieces into smaller, more focused files
- More importantly, this sets the groundwork for separating the Router
state from the individual navigation transition. That is, it would be
good for the rxjs pipeline to _not_ modify the Router state but only
keep track of its own intermediate stages and emit outwards during
important events. The Router can subscribe to those events and make
updates to its state. This would theoretically allow us to swap those
implementations independently. That is, the Router's state management
can be changed without changing the transition handling and
vice-versa.
PR Close#48092
The Router currently silently ignores navigations for two reasons:
1. By default, same URL navigations are ignored. When this situation is
encountered, the navigation is ignored without any events
2. A `UrlHandlingStrategy` may ignore some URLs. For situations when the
strategy returns `false` for `shouldProcessUrl`, the Router silently
ignores the URL and updates its internal state without running
matching, guards, or resolver logic.
This commit adds new `NavigationSkipped` events for the above two situations.
PR Close#48024
None of the public properties of the `Router` are meant to be writeable.
They should all be configured using other methods, all of which have been
documented.
DEPRECATED: router writable properties
The following strategies are meant to be configured by registering the
application strategy in DI via the `providers` in the root `NgModule` or
`bootstrapApplication`:
* `routeReuseStrategy`
* `titleStrategy`
* `urlHandlingStrategy`
The following options are meant to be configured using the options
available in `RouterModule.forRoot` or `provideRouter`.
* `onSameUrlNavigation`
* `paramsInheritanceStrategy`
* `urlUpdateStrategy`
* `canceledNavigationResolution`
The following options are available in `RouterModule.forRoot` but not
available in `provideRouter`:
* `malformedUriErrorHandler` - This was found to not be used anywhere
internally.
* `errorHandler` - Developers can instead subscribe to `Router.events`
and filter for `NavigationError`.
PR Close#48006
The router has several default strategy implementations that are either
assigned via `new XStrategy()` property assignements or via the factory
function for the `Router` itself. These can be simplified by providing
the default implementation in the strategy `Injectable`. Custom
implementations can still override the defaults by specifying them in
the `providers` list.
Notably, this change also makes the `UrlHandlingStrategy` and
`RouteReuseStrategy` defaults injectable via DI rather than having to
indirectly grab them by going through the `Router` instance and
accessing the properties.
PR Close#48022
The `setupTestingRouter` function is not necessary. The `Router` can be fully
initialized through the DI configuration in the same way as it is in
production. Tests should use `provideRouter` or `RouterTestingModule`.
PR Close#48008
This commit updates the logic related to the attribute and property binding rules for <iframe> elements. There is a set of <iframe> attributes that may affect the behavior of an iframe and this change enforces that these attributes are only applied as static attributes, making sure that they are taken into account while creating an <iframe>.
If Angular detects that some of the security-sensitive attributes are applied as an attribute or property binding, it throws an error message, which contains the name of an attribute that is causing the problem and the name of a Component where an iframe is located.
BREAKING CHANGE:
Existing iframe usages may have security-sensitive attributes applied as an attribute or property binding in a template or via host bindings in a directive. Such usages would require an update to ensure compliance with the new stricter rules around iframe bindings.
PR Close#47964
[A Github issue](https://github.com/angular/angular/issues/43821) about an arcane-sounding Forms error is one of the repo's top-ten most visited pages. This converts the error to `RuntimeErrorCode` and adds a dedicated guide to explain how to solve it.
PR Close#47969
The public API for enabling this option has already been removed. This change
updates the internal Router code to not include any logic to support it.
PR Close#47933
This function is too similar in name to the new `provideRouter` and can
lead to misconfiguring the router. The function itself is just a small
wrapper around `{provide: ROUTES, multi: true, useValue: routes}`. It is
rarely necessary to provide routes in this way. The harm `provideRoutes`
will cause due to being only 1 letter away from `provideRouter` vastly
outweighs the benefit of a slightly shorter provider.
PR Close#47896
This rename reflects what the function actually does. Although the intention
is still not to have two different interceptor mechanisms, that is now
communicated in the docs for the function instead of in its name.
Fixes#47764
PR Close#47901
This reverts commit 2d08965b1a.
The reason for revert is that we've identified some issues with implementation. The issues will get addressed soon and the fix would be re-submitted.
PR Close#47959
This commit updates the logic related to the attribute order on iframes and makes the rules more strict. There is a set of iframe attributes that may affect the behavior of an iframe, this change enforces that these attributes are applied before an `src` or `srcdoc` attributes are applied to an iframe, so that they are taken into account.
If Angular detects that some of the attributes are set after the `src` or `srcdoc`, it throws an error message, which contains the name of ann attribute that is causing the problem and the name of a Component where an iframe is located. In most cases, it should be enough to change the order of attributes in a template to move the `src` or `srcdoc` ones to the very end.
BREAKING CHANGE:
Existing iframe usages may have `src` or `srcdoc` preceding other attributes. Such usages may need to be updated to ensure compliance with the new stricter rules around iframe bindings.
PR Close#47935
This commit updates the NgOptimizedImage directive to:
- drop a deprecated selector (the `rawSrc` one)
- drop corresponding input getter
The `rawSrc` was replaced by the `ngSrc` one during the developer preview phase.
PR Close#47798
This commit adds a missing warning if the image directive
detects that you're hosting your image on one of our
supported image CDNs but you're not using the built-in loader
for it. This excludes applications that are using a custom
loader.
PR Close#47330
Implements more of the runtime validations for host directives as compiler diagnostics so that they can be caught earlier. Also does some minor cleanup.
PR Close#47768
Prior to this, the `@angular/localize/init` was added as a polyfill which caused the `@angular/localize` types not to be included in the TypeScript program which caused errors such as the below:
```
Error: src/app/app.component.ts:9:11 - error TS2304: Cannot find name '$localize'.
```
With the recent changes in the CLI (https://github.com/angular/angular-cli/pull/24032), adding `@angular/localize/init` as polyfil or in the `main.server.ts` is no longer necessary. Instead we add this as a TypeScript type. When users are running in JIT mode, we add `@angular/localize/init` as an additional entrypoint.
This change also exposes the `$localize` method as a global when importing `@angular/localize`.
Closes#47677
PR Close#47763
This commit updates the `provideHttpClient` function to return the `EnvironmentProviders` instead of a regular `Provider[]`, to make sure that the `provideHttpClient` can only be used where an environment is being setup.
PR Close#47758
Add a new boolean attribute to NgOptimizedImage called `fill` which does the following:
* Removes the requirement for height and width
* Adds inline styling to cause the image to fill its containing element
* Adds a default `sizes` value of `100vw` which will cause the image to have a responsive srcset automatically generated
PR Close#47738
Previously, `setDisabledState` was never called when attached if the control is enabled. This PR fixes the bug, and creates a configuration option to opt-out of the fix.
Fixes#35309.
BREAKING CHANGE: setDisabledState will always be called when a `ControlValueAccessor` is attached. You can opt-out with `FormsModule.withConfig` or `ReactiveFormsModule.withConfig`.
PR Close#47576
In AOT compilations, the `strictInjectionParameters` compiler option can
be enabled to report errors when an `@Injectable` annotated class has a
constructor with parameters that do not provide an injection token, e.g.
only a primitive type or interface.
Since Ivy it's become required that any class with Angular behavior
(e.g. the `ngOnDestroy` lifecycle hook) is decorated using an Angular
decorator, which meant that `@Injectable()` may need to have been added
to abstract base classes. Doing so would then report an error if
`strictInjectionParameters` is enabled, if the abstract class has an
incompatible constructor for DI purposes. This may be fine though, as
a subclass may call the constructor explicitly without relying on
Angular's DI mechanism.
Therefore, this commit excludes abstract classes from the
`strictInjectionParameters` check. This avoids an error from being
reported at compile time. If the constructor ends up being used by
Angular's DI system at runtime, then the factory function of the
abstract class will throw an error by means of the `ɵɵinvalidFactory`
instruction.
In addition to the runtime error, this commit also analyzes the inheritance
chain of an injectable without a constructor to verify that their inherited
constructor is valid.
BREAKING CHANGE: Invalid constructors for DI may now report compilation errors
When a class inherits its constructor from a base class, the compiler may now
report an error when that constructor cannot be used for DI purposes. This may
either be because the base class is missing an Angular decorator such as
`@Injectable()` or `@Directive()`, or because the constructor contains parameters
which do not have an associated token (such as primitive types like `string`).
These situations used to behave unexpectedly at runtime, where the class may be
constructed without any of its constructor parameters, so this is now reported
as an error during compilation.
Any new errors that may be reported because of this change can be resolved either
by decorating the base class from which the constructor is inherited, or by adding
an explicit constructor to the class for which the error is reported.
Closes#37914
PR Close#44615
This commit adds a logic that generates preload tags for priority images, when rendering happens on the server (e.g. Angular Universal).
PR Close#47343
This commit exports existing utility functions to check for control instances:
isFormControl, isFormGroup, isFormRecord, isFormArray
Those are useful when implementing validators that use the specifics of one of those control types.
To narrow down the type to what it actually is, we can now use the util functions in validators:
```
export const myArrayValidator: ValidatorFn = (control) => {
if (!isFormArray(control)) { return null; }
// now you can use FormArray-specific members, e.g.:
if (control.controls.every(c => !!c.value) {
return { myerror: true }
} else { return null; }
}
```
PR Close#47718
This commit adds the `provideLocationMocks()` function that returns mocks for the `Location` and `LocationStrategy` classes. This function can be used in tests to configure an environment where it's possible to fire simulated location events (helpful when testing Router configuration).
PR Close#47674
Add a feature to automatically generate the srcset attribute for images using the NgOptimizedImage directive. Uses the 'sizes' attribute to determine the appropriate srcset to generate.
PR Close#47547
Matthieu Riegler