Exposes the function used to transform an input on `ComponentFactory.inputs` and `ComponentMirror.inputs`. We'll need this to support input transforms in `elements`.
PR Close#50713
If a library is compiling with Angular v16.1.0, the library will break
for users that are still on Angular v16.0.x. This happens because the
`DirectiveDeclaration` or `ComponentDeclaration` types are not expecting
an extra field for `signals` metadata. This field was only added to the
generic types in `16.1.0`- so compilations fail with errors like this:
```
Error: node_modules/@angular/material/icon/index.d.ts:204:18 -
error TS2707: Generic type 'ɵɵComponentDeclaration' requires between 7 and 9 type arguments.
```
To fix this, we quickly roll back the code for inserting this metadata
field. That way, libraries remain compatible with all v16.x framework
versions.
We continue to include the `signals` metadata if `signals: true` is set.
This is not public API anyway right now- so cannot happen- but imagine
we expose some signal APIs in e.g. 16.2.x, then we'd need this metadata
and can reasonably expect signal-component library users to use a more
recent framework core version.
PR Close#50714
The component exposed by the fixture is not important thus marked as `unknown`.
Exposing the fixture of the `RouterTestingHarness` allows to use the methods & properties of that fixture and makes it compatible with testing libraries relying on `ComponentFixture`
Fixes#48855
PR Close#50280
Extend toSignal to accept any Subscribable (instead of only Observable)
for consistency with AsyncPipe and for broader compatibility with any
observable library (that is compatible with the Subscribable interface).
This is only a type change as the implementation does not use anything
else than the Subscribable interface anyway.
PR Close#50162
This commit refactors the code of NgOptimizedImage directive to switch from getter/setter approach to convers inputs to use the `transform` function instead.
PR Close#50580
This commit introduces a new `HttpBackend` implentation which makes requests using the fetch API
This feature is a developer preview and is opt-in.
It is enabled by setting the providers with `provideHttpClient(withFetch())`.
NB: The fetch API is experimental on Node but available without flags from Node 18 onwards.
PR Close#50247
According to the HTML specification most attributes are defined as strings, however some can be interpreted as different types like booleans or numbers. [In the HTML standard](https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#boolean-attributes), boolean attributes are considered `true` if they are present on a DOM node and `false` if they are omitted. Common examples of boolean attributes are `disabled` on interactive elements like `<button>` or `checked` on `<input type="checkbox">`. Another example of an attribute that is defined as a string, but interpreted as a different type is the `value` attribute of `<input type="number">` which logs a warning and ignores the value if it can't be parsed as a number.
Historically, authoring Angular inputs that match the native behavior in a type-safe way has been difficult for developers, because Angular interprets all static attributes as strings. While some recent TypeScript versions made this easier by allowing setters and getters to have different types, supporting this pattern still requires a lot of boilerplate and additional properties to be declared. For example, currently developers have to write something like this to have a `disabled` input that behaves like the native one:
```typescript
import {Directive, Input} from '@angular/core';
@Directive({selector: 'mat-checkbox'})
export class MatCheckbox {
@Input()
get disabled() {
return this._disabled;
}
set disabled(value: any) {
this._disabled = typeof value === 'boolean' ? value : (value != null && value !== 'false');
}
private _disabled = false;
}
```
This feature aims to address the issue by introducing a `transform` property on inputs. If an input has a `transform` function, any values set through the template will be passed through the function before being assigned to the directive instance. The example from above can be rewritten to the following:
```typescript
import {Directive, Input, booleanAttribute} from '@angular/core';
@Directive({selector: 'mat-checkbox'})
export class MatCheckbox {
@Input({transform: booleanAttribute}) disabled: boolean = false;
}
```
These changes also add the `booleanAttribute` and `numberAttribute` utilities to `@angular/core` since they're common enough to be useful for most projects.
Fixes#8968.
Fixes#14761.
PR Close#50420
Adds the necessary compiler changes to support input transform functions. The compiler output has changed in the following ways:
### Directive handler
The directive handler now extracts a reference to the input transform function and it resolves the type of its first parameter. It also asserts that the type can be referenced in the compiled output and that it doesn't clash with any pre-existing `ngAcceptInputType_` members.
### .d.ts
In the generated declaration files the compiler now inserts an `ngAcceptInputType_` member for each input with a `transform` function. The member's type corresponds to the type of the first parameter of the function, e.g.
```typescript
// foo.directive.ts
@Directive()
export class Foo {
@Input({transform: (incomingValue: string) => parseInt(incomingValue)}) value: number;
}
// foo.directive.d.ts
export class Foo {
value: number;
static ngAcceptInputType_value: string;
}
```
### Type check block
If an input has `transform` function, the TCB will use the type of its first parameter for the setter type. This uses the same infrastructure as the `ngAcceptInputType_` members.
### Directive declaration
The generated runtime directive declaration call now includes the `transform` function in the `inputs` map, if the input is being transformed. The function will be picked up by the runtime in the next commit to do the actual transformation.
```typescript
// foo.directive.ts
@Directive()
export class Foo {
@Input({transform: (incomingValue: string) => parseInt(incomingValue)}) value: number;
}
// foo.directive.js
export class Foo {
ɵdir = ɵɵdefineDirective({
inputs: {
value: ['value', 'value', incomingValue => parseInt(incomingValue)]
}
});
}
```
PR Close#50225
Hydration requires a stable App to run some logic.
With this warning developers will be informed about potential issues encountered when running an unstable app.
Fixes#50285
PR Close#50295
Unlike the current signature where the input argument must a function, this change allows an input of any type to be passed to the `isSignal` function.
PR Close#50035
Using `@angular/platform-browser-dynamic` is no longer required for JIT scenarios with Ivy. Instead `@angular/compiler` should be imported instead.
This change is part of the effort to reduce the server bundles sizes, which is needed to support cloud workers.
BREAKING CHANGE:
Users that are using SSR with JIT mode will now need to add `import to @angular/compiler` before bootstrapping the application.
**NOTE:** this does not effect users using the Angular CLI.
PR Close#50064
This commit introduces an interface for `toSignal` options to mirror that of
`toObservable`, and adjusts docs for both symbols. It also adds the ability
for `toSignal` to manually specify `DestroyRef` (similarly to
`toObservable` accepting an injector) or for `toSignal` automatic cleanup to
be disabled (in which case the subscription persists until the Observable
completes). Either option allows `toSignal` to be used outside of a DI
context, like `toObservable`.
PR Close#50071
This commit adds the `signals: boolean` property to the internal
directive/component metadata. This does not add it to the public API
yet, as the feature has no internal support other than compiler
detection.
PR Close#49981
Hydration relies on a signal from ZoneJS when it becomes stable inside an application, so that Angular can start serialization process on the server or post-hydration cleanup on the client (to remove DOM nodes that remained unclaimed).
Providing a custom or a "noop" ZoneJS implementation may lead to a different timing of the "stable" event, thus triggering the serialization or the cleanup too early or too late. This is not yet a fully supported configuration.
This commit adds a warning (non-blocking) for those cases.
PR Close#49944
In this mode the compiler generates code based on each individual source file without using its dependencies. This mode is suitable only for fast edit/refresh during development.
PR Close#49846
It might happen that the lifecycle scope represented by DestroyRef becomes
invalid before an onDestroy hook is registered (ex. injector or component
instance got destroyed). In such cases registration of the onDestroy hooks
should no longer be possible.
Fixes#49658
PR Close#49804
The new asReadonly method on the WritableSignal interface makes
it possible to create readonly instance of a writable signal.
Readonly signals can be accessed to read their value,
but can't be changed using set, update or mutate methods.
PR Close#49802
Some libraries could use numbers in headers. this fix prevents Angular from
throwing an error by casting those numerical values into strings.
Fixes#49353
PR Close#49379
The initial value used for signals by default is now `undefined`. In
addition, there is a new option to express that the signal should emit a
value synchronously (`requireSync: true`). When this value is specified,
the function will throw _on creation_ if the subscribing to the
`Observable` does not result in a synchronous emit.
PR Close#49769
Paul Gschwendtner