The Future of RxJS in Angular

Dec 20, 2024 · Angular · Alejandro Cantero Jódar

What changes have been made to RxJS integration in Angular version 19?

Version 19 of the framework continues with the integration of signals as a more native and declarative way to handle change detection within applications. Until now, Angular has heavily relied on Zone.js for change detection and RxJS for handling asynchronous events and reactivity. But with signals, Google aims to gradually free itself from Zone.js and improve performance, providing us with a more agile alternative.

Despite these advances, Angular 19 does not remove RxJS or replace it entirely. Instead, it introduces a compatibility layer that allows developers to work with both signals and Observables, depending on user preference or project needs. This gradual transition suggests that Angular is looking to reduce dependency on RxJS without forcing an abrupt migration, which can be seen as a strategy to make the framework more accessible to new developers without alienating experts who are already familiar with RxJS.

Using resource() in Angular 19

One of the most interesting new features is the introduction of resource(), an experimental API for handling asynchronous operations without needing to rely on RxJS. This function allows for managing data loading, error handling, and manual value updates in a much simpler way.

For example, suppose we have a product management system where we want to fetch product details based on its ID:

import { resource, signal, computed } from '@angular/core'

// We have a signal that represents the product ID.
productId = signal(1)

// Define a resource that fetches the product data each time the productId changes.
productResource = resource({
  request: () => ({ id: productId() }), // this is a computation function
  loader: ({ request }) => fetch(`/products/${request.id}`)
})

// Then, you can use the resource value as signal.
price = computed(() => productResource.value().price)

Each time the value of productId changes, productResource will automatically update the product state without needing to manually subscribe in the constructor or the OnInit event.

The fact that resource() receives a promise means that the dependency on RxJS is no longer the default way of handling asynchronicity. Angular can manage asynchronous data flows without requiring Observables, which significantly simplifies the learning curve for new developers.

Interoperability with RxJS

Despite these improvements, Angular still maintains interoperability with RxJS for those who wish to continue using it. A clear example of this is rxResource(), which allows using an Observable, integrating it with RxJS tools and operators without losing the efficiency of the new signal-based system:

import { rxResource, inject, signal } from '@angular/core'
import { HttpClient } from '@angular/common/http'

http = inject(HttpClient)

productId = signal(1)

productResource = rxResource({
  request: () => ({ id: productId() }), // this is a computation function
  loader: ({ request }) => this.http.get(`/products/${request.id}`) // this is an Observable
})

With this, developers who already have RxJS-based code can continue leveraging its advantages without losing compatibility with the new features of Angular 19.

So, what is the fate of RxJS in Angular?

RxJS remains a powerful and useful library, especially when handling asynchronous events, global state management, and complex data flows efficiently. Its interoperability with Angular remains robust, and many community libraries and patterns have evolved around its use.

While signals offer a more "native" solution, RxJS still provides advanced tools for managing complex data flows.

It is worth noting that signals exist within the context of a component and not in services, where a library like RxJS or Redux might take center stage.

In this sense, the best recommendation at this moment is to wait and see how this relationship between Angular and RxJS evolves. Over time and with community feedback, we will see if RxJS continues to be a fundamental part of the framework.

It seems evident that the trend is towards a much simpler and less opinionated Angular, without Zone.js or RxJS by default. However, the transition towards elimination will not be easy nor as smooth as we users might like.