mirror of
https://github.com/angular/angular
synced 2026-05-24 09:28:37 +00:00
48974c3cf8
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 |
||
|---|---|---|
| .. | ||
| src | ||
| test | ||
| BUILD.bazel | ||
| index.ts | ||
| PACKAGE.md | ||
| public_api.ts | ||