For years, RxJS has been a cornerstone of reactivity in Angular. However, one of its main drawbacks in terms of synchronizing data and view is its stateless nature. Conceptually, observables are more about handling events than managing data. In response, the Angular team introduced a new primitive — Signals. But how should we approach RxJS now?
As mentioned earlier, the core concept of observables revolves around notifications. Streams and their operators excel at describing complex event-driven logic, especially when dealing with imperative APIs in a browser environment. With Angular now introducing tools to enable seamless interaction between signals and observables, we have an incredibly powerful synergy at our disposal.
In this article, I’ll showcase some examples of code where these two concepts complement each other.
Let's follow a simple rule:
No more observables in templates. Bye | async 👋
No more observables in templates. Bye | async 👋
Before signals were introduced, reactivity in Angular relied on subscribing to observables within templates using the AsyncPipe. This pipe was designed to solve two key tasks: marking a view as dirty for change detection (it’s necessary when using the OnPush strategy) and tying into the component’s lifecycle to unsubscribe from the observable when its view is destroyed.
However, it didn’t solve the fundamental issue I mentioned earlier: observables don’t guarantee a state upon subscription, which led Angular to type the pipe’s return value as a union with null. This forced developers to add extra checks, which turned out to be pretty annoying.
Now, it’s time to fully transition away from using observables in templates and embrace signals, which are inherently stateful and offer additional benefits that we’ll discuss in the examples.
⚠️ Warning: The code examples use the RxJS Interop API, which is still in developer preview.
📋 Copy button
Let’s solve a simple task: when a copy button is clicked, we want to provide feedback to the user by changing the icon and text for a couple of seconds, then reverting it back to the original state:
readonly copied = toSignal(
fromEvent(inject(ElementRef).nativeElement, 'click').pipe(
exhaustMap(() =>
timer(2000).pipe(
map(() => false),
startWith(true)
)
)
),
{ initialValue: false }
);
Result (stackblitz):
Taking advantage of RxJS operators, we declaratively described how the copied state changes:
- If the user clicks the button multiple times,
exhaustMapensures that the currenttimercompletes properly before resetting the state tofalse - The logic for synchronizing emitted values with a signal and unsubscribing from the source observable is handled by toSignal, eliminating the need for manual subscriptions
💡 Referring to the point in the previous section about not using AsyncPipe, we can use the new alternative for streams in the form of toSignal.
✨ Anchor highlighter
Let’s move on to a slightly more challenging task. Our page contains anchor links that should be highlighted when the user navigates to a URL with the corresponding fragment. Since the section containing the link may be outside the viewport during navigation, the highlight should only be applied after the automatic scrolling is complete:
private readonly id = inject(new HostAttributeToken('id'));
private readonly route = inject(ActivatedRoute);
readonly highlighted = toSignal(
this.route.fragment.pipe(
startWith(this.route.snapshot.fragment),
filter(fragment => this.id === fragment),
switchMap(() =>
concat(
fromEvent(window, 'scroll').pipe(
startWith(true),
debounceTime(100),
take(1)
),
timer(2000).pipe(map(() => false))
)
)
),
{ initialValue: false }
);
By the way, another drawback of observables when managing state was the inability to bind data directly to a host element. Signals solve this issue, enabling us to do this:
Result (stackblitz):
host: {
'[class.highlighted]': 'highlighted()'
}
👻 Automatic dismissal
Let’s tackle the task of implementing a notification component with automatic dismissal. It accepts a display duration as input and emits an event when it should close. Additionally, there’s one more requirement: if a user hovers over the notification, the timer should be stopped and reset, preventing dismissal until the cursor leaves the element:
Result (stackblitz):
private readonly el = inject(ElementRef).nativeElement;
readonly duration = input(Infinity);
readonly close = outputFromObservable(
toObservable(this.duration).pipe(
switchMap(value => Number.isFinite(value) ? timer(value) : EMPTY),
takeUntil(fromEvent(this.el, 'mouseenter')),
repeat({ delay: () => fromEvent(this.el, 'mouseleave') })
)
);
In this task, we utilized two utility functions to work with Angular’s updated input and output APIs:
toObservable: converts our signal-based input into a stream. Angular has done an excellent job of enhancing its reactivity system, making input properties of directives and components truly reactive. These properties can now be utilized both in state management scenarios (e.g., with computed properties) and for creating logic based on interaction with observables.
⚠️ It is crucial to note that signals are inherently glitch-free and never propagate changes synchronously. If a signal’s value is updated synchronously multiple times, the subscriber will only be notified of the latest value once the signal stabilizes during the change detection process. It’s important to keep in mind if you plan to build reactive chains using toObservable.
outputFromObservable: creates a new output from an observable. With the introduction of new inputs, Angular needed to move away from EventEmitter, which was previously extended from RxJS’s Subject. While there’s nothing groundbreaking here, the output now uses an instance of a new class OutputEmitterRef under the hood. This class essentially follows the same mental model as Subject but in a more lightweight form.
📏 Tracking an element’s dimensions
When it comes to APIs in the browser environment, it can be inconvenient to use them in a declarative manner. Most of these APIs are callback-based, and some also include cleanup logic, similar to what is known in the RxJS world as TeardownLogic.
However, while RxJS provides a unified mechanism for building reactive chains, working with imperative APIs often demands writing more verbose and consistent instructions.
Since signals integrate seamlessly with observables, it’s simple to treat imperative APIs as streams. For example, let’s define a custom operator to turn ResizeObserver into an observable:
export function fromResizeObserver(
target: Element,
options?: ResizeObserverOptions,
): Observable<ResizeObserverEntry[]> {
return new Observable(subscriber => {
const ro = new ResizeObserver(entries => subscriber.next(entries));
ro.observe(target, options);
return () => ro.disconnect();
});
}
💡 This operator can be reused throughout the codebase. For instance, we can use it to create a reactive state for the width of a host element:
private readonly el = inject(ElementRef).nativeElement;
readonly width = toSignal(
fromResizeObserver(this.el).pipe(map(() => this.el.offsetWidth)),
{ initialValue: 0 }
);
Accurately tracking an element’s width often requires more than just ResizeObserver. Edge cases may necessitate using additional observers like MutationObserver. This is where RxJS excels: by leveraging merging operators, we can declaratively combine events to reliably detect changes in an element’s width:
private readonly el = inject(ElementRef).nativeElement;
readonly width = toSignal(
merge(
fromResizeObserver(this.el),
fromMutationObserver(this.el, {
childList: true,
subtree: true,
characterData: true,
})
// ...and any other edge cases
).pipe(
map(() => this.el.offsetWidth),
distinctUntilChanged()
),
{ initialValue: 0 }
);
🔋 Boosting Angular APIs
In the previous example, we created a custom operator to wrap a browser-specific API. A similar approach can be applied to building reactive interactions with some of Angular’s APIs by creating observables based on them.
In some of the previous code snippets, I used global objects available only in the browser environment (e.g., window). However, to guarantee proper code execution on the server (SSG / SSR), we need to ensure that certain logic is initialized only during client-side rendering. In such cases, we could use the afterNextRender API (⚠️ still in developer preview), which is based on a callback, and turn it into an observable:
export function fromAfterNextRender(options?: AfterRenderOptions): Observable<void> {
if (!options?.manualCleanup && !options?.injector) {
assertInInjectionContext(fromAfterNextRender);
}
return new Observable(subscriber => {
const ref = afterNextRender(() => {
subscriber.next();
subscriber.complete();
}, options);
return () => ref.destroy();
});
}
Then, we can use it to compute the state exclusively on the client side:
readonly state = toSignal(
fromAfterNextRender().pipe(
switchMap(() => {
// here, we are in the context of the browser
}),
),
);
💡 Another example could be creating a custom operator based on a frequent sequence of operations to reduce boilerplate and improve readability.
In one of my projects, there was a lot of application logic tied to Router events, so instead of writing it like this:
private readonly router = inject(Router);
constructor() {
this.router.events.subscribe(e => {
if (e instanceof NavigationEnd) {
// The type narrowing of `e` is only available within this block
}
})
}
It’s much more convenient to write like this:
/*
Now, we can use the observable with the typed value
of the corresponding event in any way we need ✨
Returns Observable<NavigationEnd>
*/
fromRouterEvent(NavigationEnd);
To achieve this, it’s enough to write a trivial operator using the existing filter operator and a type predicate to ensure type narrowing:
import { Event, Router } from '@angular/router';
export function fromRouterEvent<T extends Event>(
event: { new (...args: any[]): T },
options?: { injector: Injector },
): Observable<T> {
let router: Router;
if (!options?.injector) {
assertInInjectionContext(fromRouterEvent);
router = inject(Router);
} else {
router = options.injector.get(Router);
}
return router.events.pipe(filter((e: unknown): e is T => e instanceof event));
}
In other words, we have the ability to adapt the framework’s necessary APIs and frequent operations to work with streams, significantly reducing boilerplate code and making it more declarative.
Conclusion
The examples described above are practical tasks from real-world projects. As demonstrated in their solutions, RxJS is perfectly suited for handling event-driven tasks. Furthermore, the reactive library remains integrated into the Angular ecosystem at the level of public APIs (e.g., in @angular/{router,forms,сommon/http,cdk}).
🌗 The synergy between signals and observables could mark an important step forward in Angular’s reactivity, offering a more structured approach where signals focus on state management and observables handle events.
🫡 Stay tuned for the next article, where we’ll explore even more advanced topics, such as optimizing performance with Signals and leveraging RxJS for complex use cases!
