This change contains multiple cleanups in the AppComponent:
- remove unused code;
- use router input bindings instead of manual read from
the active route;
- remove isBrowser checks from even handlers (click events
should not be invoked on the server, right?)
PR Close#58897
This fixes an issue with packages managers likes pmpm
that will not link the @angular/compiler package to the @angular/core
package if it is not listed as a peer dependency.
I added it as optional peer dependency as it's only used in special cases.
Fixes#38096
PR Close#55610
This commit updates error reporting of defer blocks to go to the
application root error handler rather than the `ErrorHandler` token that
may be provided by users. This ensures Angular has control over what
happens when these errors are reported.
PR Close#60149
Prior to this change, cyclic injection didn't trigger any error in prod mode, resulting into injecting the `CIRCULAR` object.
This could lead to strange errors where no method would be found on the token.
fixes#60074
PR Close#60118
The PR introduces a few doc content rendering fixes:
- Fix highlighted section heading styles (regression from #59965).
- Convert JSDoc links within 'Usage Notes' sections to HTML and render them.
- Add IDs to doc content headings. This, by itself, makes these headings available in the page ToC.
PR Close#60116
Narrows down the versions of TypeScript we need to support.
BREAKING CHANGE:
* TypeScript versions less than 5.8 are no longer supported.
PR Close#60197
Prior to this commit, the tags from the type definition were dropped.
Tags may include, but are not limited to, deprecation information from
the jsdoc.
PR Close#59524
`AsyncPipe` would previously promise rejections unhandled and
subscription errors uncaught. This is more or less fine in a Zone-based
application because errors inside the Angular Zone are caught be the
Zone's error trap and reported to `ErrorHandler`. However, in zoneless
applications, these errors are never caught or reported by the FW and
can reach the node process in SSR and cause it to shut down.
BREAKING CHANGE: `AsyncPipe` now directly catches unhandled errors in
subscriptions and promises and reports them to the application's
`ErrorHandler`. For Zone-based applications, these errors would have
been caught by ZoneJS and reported to `ErrorHandler` so the result is
generally the same. The change to the exact mechanism for reporting can
result in differences in test environments that will require test
updates.
PR Close#60057
This change introduces a new DI profiler event:
InjectorToCreateInstanceEvent. This new event allows
us to measure DI tokens instantiation time.
PR Close#60158
Reworks the `InputBinding` and `OutputBinding` functionality to be in object literals constructed in functions, rather than classes, because it seems like Terser was having a hard time tree shaking the classes when the functions weren't used.
PR Close#60137
Adds the new `outputBinding` function that allows users to listen to outputs on dynamically-created components in a similar way to templates. For example, here we create an instance of `MyCheckbox` and listen to its `onChange` event:
```ts
interface CheckboxChange {
value: string;
}
createComponent(MyCheckbox, {
bindings: [
outputBinding<CheckboxChange>('onChange', event => console.log(event.value))
],
});
```
Note that while it has always been possible to listen to events like this by getting a hold of of the instance and subscribing to it, there are a few key differences:
1. `outputBinding` behaves in the same way as if the event was bound in a template which comes with some behaviors like forwarding errors to the `ErrorHandler` and marking the view as dirty.
2. With `outputBinding` the listeners will be cleaned up automatically when the component is destroyed.
3. `outputBinding` accounts for host directive outputs by binding to them through the host. E.g. if the `onChange` event above was coming from a host directive, `outputBinding` would bind to it automatically.
Currently `outputBinding` is available only in `createComponent`, `ViewContainerRef.createComponent` and `ComponentFactory.create`, but it will serve as a base for APIs in the future.
PR Close#60137
Calling `setInput` while the component already has an `inputBinding` active can lead to inconsistent state. These changes add an error that will be thrown if that's the case.
PR Close#60137
Adds the ability to bind to inputs on dynamically-created components, either by targeting the component itself or one of its directives. The new API looks as follows:
```ts
const value = signal(123);
createComponent(MyComp, {
// Bind the value `'hello'` to `someInput` of `MyComp`.
bindings: [inputBinding('someInput', () => 'hello')],
directives: [{
type: MyDir,
// Bind the `value` signal to the `otherInput` of `MyDir`.
bindings: [inputBinding('otherInput', value)]
}]
});
```
This behavior overlaps with `ComponentRef.setInput`, with a few key differences:
1. `setInput` sets the value on *all* inputs whereas `inputBinding` only targets the specified directive and its host directives. This makes it easier to know which directive you're targeting.
2. `inputBinding` is executed as if it's in a template, making it consistent with how bindings behave for selector-matched components, whereas `setInput` executes outside the lifecycle of the component.
3. It resolves a long-standing issue with `setInput` where it wasn't possible to set the initial value of an input before the first change detection run.
Currently `inputBinding` is used only for `createComponent`, `ViewContainerRef.createComponent` and `ComponentFactory.create`, however it is going to be base for more APIs in the future.
PR Close#60137
Sets up the symbols used to power the upcoming `inputBinding` functionality.
I also fixed that `setDirectiveInput` was incorrectly only allowing strings for the `value` parameter.
PR Close#60137
Updates `createComponent`, `ViewContainerRef.createComponent` and `ComponentFactory.create` to allow the user to specify directives that should be applied when creating the component.
PR Close#60137
Some upcoming functionality won't work if we can't retrieve a directive definition from a class. These changes add a `throwIfNotFound` to `getDirectiveDef`, similar to `getNgModuleDef`, to avoid duplication in such cases.
PR Close#60137
The check that verifies that there are no duplicates in the directives array was only running after host directive matching since that was the only case when it can happen. After the upcoming changes that won't be the case anymore so these changes move it always run after directive matching.
I also did some additional cleanup by adding comments and by not lazily initializing the `allDirectiveDefs` array when matching host directives. The array is guaranteed to be defined since earlier in the function we verify that there's at least one def with host directives.
PR Close#60137
Matthieu Riegler