Sub-RFC 4 for Angular Signals sparks interesting discussion started by RxJS author Ben Lesh

Custom graphics generated by MidJounrey AI

Before we dive in to the interesting discussion its essential to know that everyone has the opportunity to actively participate and express their opinions on upcoming Angular modifications in public discussions under existing sub-RFCs. The focus here is sub-RFC 4.

What are Signals and sub-RFC4?

Quick intro on the whole topic of Angular Signals. In a nutshell Signals are new approach to reactivity in Angular, simplifying reactivity while simultaneously enabling fine-tuned control over component updates.

Sub-RFC 4 is taking on the important topic of interoperability with RxJS Observables, a fundamental way of how we manage reactivity in Angular applications today.

Signals and RxJS compatibility

Seamless compatibility with current RxJS-based applications and libraries is what Angular Signals aim for.

Sub-RFC 4 presents two innovative APIs, fromObservable and fromSignal, conversation between Observables and Signals. You can find them in @angular/core/rxjs-interop. Keep in mind its all work in progress.

fromObservable

convert an RxJS Observable to an Angular Signal using fromObservable:

const counter: Signal<number> = fromObservable(counter$);

Internally, fromObservable subscribes to the supplied Observable and updates the returned Signal each time the Observable emits a value. The subscription is established immediately, and Angular will automatically unsubscribe when the context in which it was created is destroyed.

Initial value

Using fromObservable, you can provide a default value to use if the Observable hasnt emitted by the time the Signal is read:

const secondsObs = interval(5000);const seconds = fromObservable(secondsObs, 0);effect(() => {  console.log(seconds());});

Error and completion states

Signals function as value wrappers, notifying consumers when the value changes. Observables, however, have three types of notifications: next, error, and complete. When an Observer created by fromObservable is notified of an error, it will throw the error the next time the Signal is read. To handle the error at the Signal usage point, you can employ catchError on the Observable side or computed on the Signal side.

Signals lack a complete concept, but you can represent the completion state using an alternative signal or the materialize operator.

fromSignal

Signal to Observable? Use fromSignal- It generates an effect that monitors the Signal and streams its values to subscribers when the Observable is subscribed to.

const count: Observable<number> = fromSignal(counterObs);

The Observable produced by fromSignal delivers all its values asynchronously. If you want to get the first value synchronously, you can use the startWith operator:

const obs$ = fromSignal(mySignal).pipe(startWith(mySignal()));

Lifecycle and Cleanup

When a fromSignal Observable is subscribed to, it creates an effect that exists until the subscriber unsubscribes. This differs from fromObservable, which automatically cleans up its subscription when the context in which it was created is destroyed.

takeUntilDestroyed

takeUntilDestroyed is a new RxJS operator that simplifies completing a stream when a related subject completes. By default, it injects the current cleanup context, allowing you to tie the lifecycle of your fromSignal Observable to a component's lifecycle:

const myValue$ = fromSignal(myValue).pipe(takeUntilDestroyed());

Conclusion

All of this has been created to allow easy way of bridging RxJS Observables and Signals. Angular team wants to minimise the impact of changes allowing us to easily work with both approaches.

The Angular Signals and Observables Debate

Now to the more interesting part. The sub-RFC 4 proposal sparked a discussion about the possibilities of integrating Angular Signals with Observables. It all comes down to whether Angular Signals should adopt globally understood common interop points like Symbol.asyncIterator and Symbol.observable.

Ben Lesh on his vision

Ben Lesh thinks that making signals fit observable chains directly is a good idea, stating that Signals inherently possess a time dimension that makes them well-suited for this. By adopting common interop points, Angular Signals could achieve better compatibility across various platforms.

Alex Rickabaugh pointing out potential issues

However, Alex Rickabaugh mentions that team has been thinking about this approach, explaining that Angular Signals have unique characteristics that make it challenging to safely read them during the change propagation phase.

Additionally, signals require an injection context, which could result in surprising and burdensome requirements when used inside Observable pipelines. Alex states that signals are not Observables, and converting between them should be an intentional operation to ensure a well-considered application architecture.

The Angular Teams Stance

Angular team remains firm in their decision not to implement InteropObservable or any Subscribable interface for Angular Signals. Although this means no immediate changes to the framework, the debate has undoubtedly generated valuable insights and raised important questions about the future of Angular Signals and Observables.

Stay informed

The Angular sub-RFC 4 debate highlights the challenges and considerations involved in enhancing Angular. As the community continues to explore these ideas discussions like this are going to happen in the end resulting in better final implementation. I believe its important to stay informed about such conversations and even participate if you feel like you have a valuable point to add to discussion.