Adds a hook in the same style as `postSignalSetFn` for running side effects when a producer has been created. This hook will be passed the reactive node being created.
PR Close#60333
This commit removes the previously added `rejectErrors` option from
`toSignal` which was meant to create similar behavior to what happens
with unhandled errors in `AsyncPipe`.
This option promotes unhandled exceptions and attaches behaviors that we
do not believe are desirable as an option offered by the framework:
* Unhandled errors that are thrown lose the context of where the error
ocurred. Throwing the error where the signal is read allows error
handling to be performed at the signal's usage location
* With this feature, the value of the signal remains set to the initial
value or the previous successful value coming out of the `Observable`.
We do not feel this is appropriate implicit behavior but should be an
explicit choice by the application. Signals are built to represent
state. When an observable stream is converted to a stateful
representation, there should be a choice made about what state should
be presented when an error occurs
* If an error occurs but the signal value is never read in its error
state, this is not an application state error that should result in an
unhandled exception.
* While Angular does not have error boundaries today, there is likely to
be investigation in the near future to address increased risk of
errors thrown from signals such as this in templates. Without
pre-designing any specifics, it is possible that this type of feature
would require the error to be thrown from the signal. We are subsequently
not prepared to commit to stabilizing the `toSignal` API with the
`rejectErrors` option and its current behavior.
Developers that desire similar behavior to `rejectErrors` have several
options, the simplest of which would be something similar to
`toSignal(myStream.pipe(catchError(() => EMPTY)))`.
PR Close#60397
The `renderApplication` and `renderModule` methods currently encapsulate the entire rendering process, making it difficult to intercept key phases from a non-Angular context. This change exports the internal `render` method, allowing us to perform operations such as:
- Flushing headers before hydration preparation
- Handling non static redirects (e.g., 302 responses)
- Intercepting router events for additional processing
This refactor serves as an experimental step toward improving the API for better customization and integration in the future.
PR Close#60416
Angular DevTools now supports mutating objects underneath signals in the property explorer view.
This is done by performing an "immutable update" by recursively copying objects underneath a signal and overwriting the one property specified. For example, if the user attempted to set `foo.bar.baz[2].hello = 'world'` and `bar` was a signal, this would effectively become:
```typescript
foo.bar.set({
...foo.bar(),
baz: [
...foo.bar().baz.slice(0, 2),
{
...foo.bar().baz[2],
hello: 'world',
},
...foo.bar().baz.slice(3),
],
})
```
The motivation for immutable updates is because signals and Angular change detection don't really like interior mutability of signal values. If we didn't do this, any kind of comparison or dirty check would prevent the UI from updating. If an application attempts to change a deeply nested property inside a signal, it doesn't work today. DevTools should generally be limited to operations an application could do itself, and the recommended approach to make such a change like this is an immutable update. Creating entirely new objects intentionally breaks referential equality such that the application can properly react to the change.
Unfortunately, it is not possible to make immutable updates in a truly generic sense. You can't just copy a class for instance `({...new MyFoo()}).doSomething()`. We could do something fancier like manually copying over the prototype or something like that, but there is no way to do this without breaking class semantics (ex. the class might reasonably rely on the constructor being called). Therefore we instead reject any mutations to non-primitive objects. In the future, we might expand the set of "primitives" to include other built-ins and well-known objects like `URL` or `Element`, but those are out of scope for now.
I opted to ban mutating the result of a readonly/computed signal. While the mutation is likely to succeed, a subsequent rerun of the `computed` will immediately drop the change. However, I opted to allow mutating the result of a getter property. This has a similar problem because it might be returning a synthetic object which will be invalidated on the next execution, but it is possible and reasonable for a getter to return the same object multiple times such that a mutation may reasonably survive other updates. DevTools can't easily know whether a getter actually will return the same object on each execution or not, so we optimistically assume the reference is stable. If it isn't, the mutation will be lost whenever the getter is re-executed.
PR Close#60381
Sometimes `forest` can be empty if the provided roots are empty, and was leading to a "Cannot read `resolutionPath` of `undefined`" error. Now we check the forest has a tree in it before looking up `resolutionPath`.
There might be a separate issue with the fact that the backend script likely shouldn't be emitting an empty forest in the first place. However we already check that a resolution path exists at all, so I think it's fair to also check that a tree was provided. We can separately look into making sure the backend is emitting valid data.
PR Close#60403
Improves the partial compliance golden generation to not rely on large
files being transmitted via `stdout`. Instead the files are written
directly as it's done in idiomatic Bazel generation actions.
In addition, we add extra stdout logging for the Bazel action, to see if
the process is actually invoked in RBE workers. Right now those are
occassionally stuck, but neither us, nor the RBE team can see anything
running, and they're occasionally stuck for 1hr.
PR Close#60427
This commit updates the server rendering documentation and merges the prerendering, hybrid, and SSR sections for better clarity and organization.
Closes#52884 and closes#60079
PR Close#60383
Builds on the changes from #60137 to add support for two-way bindings on dynamically-created components. Example usage:
```typescript
import {createComponent, signal, twoWayBinding} from '@angular/core';
const value = signal('');
createComponent(MyCheckbox, {
bindings: [
twoWayBinding('value', value),
],
});
```
In the example above the value of `MyCheckbox` and the `value` signal will be kept in sync.
PR Close#60342
Historically Angular's type checking only extended to templates, however host bindings can contain expressions as well which can have type checking issues of their own. These changes expand the type checking infrastructure to cover the `host` object literal, `@HostBinding` decorators and `@HostListener` with full language service support coming in future commits.
Note that initially the new functionality is disabled by default and has to be enabled using the `typeCheckHostBindings` compiler flag.
PR Close#60267
Sets up the logic that produces the information necessary to type check host bindings of a component. Also introduces a compiler flag for toggling checking of host bindings.
PR Close#60267
Adds the `HostElement` AST node that can be used to represent the host of a directive. Also exposes the `BindingParser` type so it's easier to pass around the return value of `makeBindingParser`.
PR Close#60267
While still being supported because of ngUpgrade, string tokens are not recommended. Developers should use InjectionTokens or classes as tokens instead.
PR Close#60326
This should prevent defer timers from impacting app stability by executing them outside of the zone, similar to other defer triggers.
fixes: #60373
PR Close#60392
Currently when we reuse a Tsurge migration is reused externally, there's some glue code that needs to be executed in a specific order. The code gets copied between the different migrations which is error-prone and means that bugs may have to be fixed several times.
These changes move the common steps out into a separate function so that only the migration-specific logic (mostly instantiation and logging) is left in the schematic.
PR Close#60386
See associated pull request for more information.
Closes#59956 as a pr takeover, `@angular/build-tooling` has been rolled back as due to missing `@aspect_rules_js`.
PR Close#60387
For internal framework values stored in injectors, they are manually
managed and inserted into injectors as needed. Therefore their tokens
don't provide a value or factory. This updates the type to reflect that
and updates the jsdocs a bit.
PR Close#60347
This commit cleans up the transition subject a bit so it doesn't use a dummy
initial value. It also avoids copying over data from the previous
request when a new one is created.
PR Close#60357
The `DowngradeComponentAdapter` adapter was assuming that all outputs are observables, but they can also be `OutputEmitterRef`.
Fixes#60366.
PR Close#60369
The signals primitives package understands the equals option now
so we can pass it to the signal / computed creation methods instead
of manually assigning the equality function on a reactive node.
PR Close#60364
This commit puts in place infrastructure capable of routing
performance-related, internal framework events directly to
the Chrome DevTools performance panel (custom track).
PR Close#60217
This change moves more logic to the primitives package by pushing
the equal configuration on a reactive node to the signal and
computed creation utilities.
PR Close#60300
