Will Signals replace RxJs? - Angular Experts

share

When Angular Signals debuted, a common question surfaced: Does this spell the end for RxJS? The quick answer is no — RxJS continues to be relevant, particularly for intricate event streams and reactive workflows. Yet, for a host of standard scenarios, Signals offer a more straightforward option, rendering RxJS non-essential and often unnecessary.

Notably, the Angular team has suggested that Observables might become non-mandatory down the line. However, for that to happen, Angular must introduce APIs that function without Observables. As it stands, several core Angular APIs—like HTTP calls and router events—emit Observables by default. Until these APIs adopt Signal-friendly alternatives, RxJS will remain a cornerstone of Angular projects.

New APIs that diminish the reliance on RxJS are already surfacing. A case in point is the new Resource API, which facilitates remote data fetching without Observables, aligning more closely with the Signal paradigm.

Despite Signals covering substantial ground, certain situations still favor RxJS, where it clearly outperforms. Let's dive into those scenarios.

Where RxJS Still Shines

Signals bring a novel approach to managing reactive state in Angular, offering a more predictable and streamlined reactivity model. However, for complex event management, RxJS remains the preferred option.

While Signals excel at state management, they aren't built for event handling. RxJS, conversely, is engineered specifically for event-driven logic and thrives in managing asynchronous data streams.

For basic event handling, RxJS might be unnecessary. But as complexity mounts—particularly with user input events, server interactions, and sophisticated data flows—RxJS and its robust operator library become vital.

Consider a practical example: a straightforward input field where users enter a username, prompting an API call to retrieve and show relevant results. Though it seems simple, this scenario involves hidden challenges:

• Requests should trigger only when the input meets a minimum character count (e.g., two).

• Redundant API requests should be prevented — continuous typing shouldn’t fire a call for every single character.

• In-flight requests need cancellation whenever a fresh search begins.

• A spinner or loading state should display during the wait for a response.

Tackling these complexities is notably tough, but with RxJS it becomes remarkably manageable. Does this imply we should avoid Signals in such cases? Not at all—the optimal approach is combining the strengths of both.

Signals + RxJS: The Best of Both Worlds

Instead of treating Signals and RxJS as rivals, view them as interlocking tools. Signals excel at streamlining state management, while RxJS continues to be crucial for handling asynchronous events.

Let’s apply the previous example and see how pairing RxJS with Signals works in practice. We’ll build a GitHub user search using both Signals and RxJS:

@Component({
  template: `
    <input (input)="searchTerm.set($any($event.target).value)"/>
      @if(!loading()){
        <ul>
          @for(user of users(); track user){
            <li>{{ user }}</li>
          }
        </ul>
      } @else {
        <div>Loading...</div>
      }
  `
})
export class App {
  #ghUsers = inject(GithubUserService);
  searchTerm = signal<string>('');
  loading = signal(false);

  users = toSignal(
    toObservable(this.searchTerm).pipe(
      debounceTime(500),
      distinctUntilChanged(),
      filter((value) => value.length > 2),
      tap(() => this.loading.set(true)),
      switchMap((value) => this.#ghUsers.getGithubUsers(value)),
      tap(() => this.loading.set(false))
    ), { initialValue: [] }
  );
}

This snippet packs quite a punch — the template is set up, a few Signals are declared, and the GithubUserService gets injected. However, the users Signal stands out as the real highlight here. Let’s dig into what makes it tick.

users = toSignal(
  toObservable(this.searchTerm).pipe(
    debounceTime(500),
    distinctUntilChanged(),
    filter((value) => value.length > 2),
    tap(() => this.loading.set(true)),
    switchMap((value) => this.ghUsers.getGithubUsers(value)),
    tap(() => this.loading.set(false))
  ), { initialValue: [] }
);

The real trick here is that we begin with a Signal, yet we bring RxJS and its operators into the picture for the asynchronous part. After the data is fully processed, we switch it back into a Signal to drive granular change detection in the view.

As a result, our code stays compact, easy to follow, and efficient — getting the best out of both RxJS and Signals at the same time.

So why not stick with the async pipe and skip Signals? Because Signals are built for the long haul and are made to work smoothly with what’s next for Angular’s change detection, even possibly paving the way for Signal-based components down the road.

Signals or Streams? Making the Right Choice

There’s plenty of uncertainty among Angular developers around the right moments for Signals, for Streams (RxJS), and for combining the two. Let’s clarify that.

I rely on a few simple guidelines every time. I begin by picking between Signals and RxJS, guided by this single question.

Before the template receives a value, I make sure that value is wrapped in a Signal. If it happens to already be a Signal, I leave it as is. But if it’s an Observable, I opt for toSignal rather than depending on the async pipe.

Signals or RxJS?

Signals open up fresh opportunities and could take over some of the territory currently covered by RxJS. Still, RxJS holds its ground as an indispensable tool in numerous scenarios. So rather than picking a side, use what fits best—or mix both approaches when the situation calls for it.

Is the code preview’s look something you like? Discover our new theme plugin

Skol - the ultimate IDE theme

Craft smarter interfaces using Angular with AI

Angular with AI: A Video Course

Get ready for what's next in Angular, and master Signals with this essential resource today.

The Angular Signals Masterclass Guide

Enjoying this? Ready to dive deep into Angular's new Signals-based forms?

Master Angular Signal Forms Hands-On

Some emails might contain extra promotional offers, check out our Privacy policy for further information.

Responses & comments

Feel free to post your questions, experiences, and viewpoints related to this subject

You might also like

Browse these additional Angular Experts blog entries to deepen your understanding of adjacent themes such as Modern Angular !

Angular Signal Forms: Custom Controls Without ControlValueAccessor

Build reusable Angular custom controls with FormValueControl, model(), touch events, and schema-driven validation—without writing a ControlValueAccessor.

emoji_objects emoji_objects emoji_objects

Kevin Kreuzer

@nivekcode

Aug 12, 2026

7 min read

Angular Signal Forms: The Missing Create/Edit Pattern

Learn a practical Angular Signal Forms pattern for create and edit flows, with route-based mode, edit data loading, linkedSignal prefilling, submit branching, and validation context.

emoji_objects emoji_objects emoji_objects

Kevin Kreuzer

@nivekcode

Aug 1, 2026

6 min read

Angular Signal Forms Essentials

Understand the core concepts behind modern Angular Forms. Learn how to create Signal Forms, wire them up in templates, use built-in and custom validators, handle cross-field validation, submit forms, and more.

emoji_objects emoji_objects emoji_objects

Kevin Kreuzer

@nivekcode

Feb 14, 2026

12 min read

Empower your team with our extensive experience

Angular Experts has accumulated years of hands-on consulting for both large enterprises and early-stage startups, delivering training sessions and tutorials while sustaining a robust library of open source projects. Our deep satisfaction comes from our knowledge of contemporary front-end systems, and we would love nothing more than to see your enterprise flourish