The Angular devkit updated Terser. Terser landed various changes
related to variable inlining. Most constants are no longer inlined,
but instead the variables are re-used.
This led to a bundle size increase of around ~600B in AIO and most
integration tests.
Here is an example diff:
https://screenshot.googleplex.com/4M8owBYDAqU982T
PR Close#49027
`setDisabledState` is supposed to be called whenever the disabled state of a control changes, including upon control creation. However, a longstanding bug caused the method to not fire when an *enabled* control was attached. This bug was fixed in v15.
This had a side effect: previously, it was possible to instantiate a reactive form control with `[attr.disabled]=true`, even though the the corresponding control was enabled in the model. (Note that the similar-looking property binding version `[disabled]=true` was always rejected, though.) This resulted in a mismatch between the model and the DOM. Now, because `setDisabledState` is always called, the value in the DOM will be immediately overwritten with the "correct" enabled value.
Users should instead disable the control directly in their model. (There are many ways to do this, such as using the `{value: 'foo', disabled: true}` constructor format, or immediately calling `FooControl.disable()` in `ngOnInit`.)
If this incompatibility is too breaking, you may also opt out using `FormsModule.withConfig` or `ReactiveFormsModule.withConfig` at the time you import it, via the `callSetDisabledState` option.
However, there is an exceptional case: radio buttons. Because Reactive Forms models the entire group of radio buttons as a single `FormControl`, there is no way to control the disabled state for individual radios, so they can no longer be configured as disabled.
In this PR, we have special cased radio buttons to ignore their first call to `setDisabledState` when in `callSetDisabledState: 'always'` mode. This preserves the old behavior.
PR Close#48864
Warn the user in the console in case the `ngSrcset` is present and no
loader is configured. In this case, the default loader is used and
it ignores this attribute.
PR Close#48804
The main entry point for the `@angular/localize` package no longer imports
the `@angular/compiler` package and now has no external dependencies. This
allows the main functionality of the package to be used without requiring
any other Angular packages. Only the message digest algorithm implementation
from the `@angular/compiler` package was being used and this code is now
bundled directly into the final npm package for `@angular/localize`.
The `tooling` secondary entry point still leverages and requires Angular
related packages (`@angular/compiler`/`@angular/compiler-cli`). However,
the tooling functionality is not intended to be used and/or bundled in
a web application.
Closes#48163
PR Close#48799
The most recent commit added extra logic that brought the payload size above the limit. Likely an actual limit was already pretty close to the threshold, so we are just updating the payload.
PR Close#48772
The `main` bundle size has increased, as well as the CSS styles from
Angular Material. Only the `main` bundle exceeded the golden, but
we update all other entries to make future updates easier and to prevent
gradually getting closer and closer to the threshold.
Investigating/comparing the `main` bundles before and after the update
did not unveil any significant changes, except for thousands of
different identifiers, with different length due to mangling. That
seems to be the only reason for having exceeded the threshold.
Very likely there were more size-affecting changes over time. Also
for example the downleveling of class fields for Safari v15 support.
See: https://github.com/angular/angular-cli/issues/24355#issuecomment-1333477033
PR Close#48747
This commit represents rewrite of the NgClass directive to address
severe performance problem (excessive DOM mutation). The modified
algorithm removes all the known performance clifs and has number of
desirable properties:
- it is shorter and (arguably) easier to follow;
- drops usage of existing differs thus limiting dependencies on other
part of the code without increasing size of the directive;
- doesn't degrade any other performance metrics.
Fixes#25518
PR Close#48433
`makeEnvironmentProviders` constructs the wrapped `EnvironmentProviders`
type, which can only be used in environment injectors (not element
injectors). It makes sense that `makeEnvironmentProviders` should be able
to accept existing `EnvironmentProviders`-wrapped providers, since it will
be providing the same guarantee, but the current types do not allow this.
This commit fixes the typings to allow nesting `EnvironmentProviders` and
adds a test to verify that it will work.
PR Close#48720
- 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
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
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
This commit removes the unnecessary `assignExtraOptionsToRouter` helper
function. This helper is not necessary because the options can be
retrieved from DI and assigned during the construction on the Router.
PR Close#48215
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
Paul Gschwendtner