Angular Signals are becoming a crucial component of contemporary Angular programming. However, RxJS continues to be a fundamental tool for managing reactive workflows and asynchronous processes.

This raises a crucial query:
Will Angular Signals take the place of RxJS?
The short answer is no.

RxJS and Angular Signals address distinct issues. While RxJS works well for asynchronous streams, API workflows, event processing, cancelation, retries, and time-based activities, signals are especially helpful for handling reactive state and UI interactions. Understanding each technology's place in a business application is preferable than seeing them as rival alternatives.

Angular Signals vs RxJS
A simple way to understand the difference is:

  • Angular Signals → Reactive state
  • RxJS → Asynchronous streams

Signals make it easier to model state and derived values.
RxJS provides operators and abstractions for working with asynchronous data and events over time.
Both can be valuable in the same Angular application.

What Are Angular Signals?
Angular Signals provide a reactive way to store and derive application state.

Consider a simple example:
import { signal, computed } from '@angular/core';

const selectedCategoryId = signal<number>(101);

const firstName = signal('John');
const lastName = signal('Doe');

const fullName = computed(() => `${firstName()} ${lastName()}`);

When firstName or lastName changes, fullName automatically reflects the new value.

This makes Signals a good fit for state that directly affects the UI.

Common Use Cases for Signals
Signals work well for:
Component state
UI state
Selected values
Filters
Toggles
Counters
Derived values
Visibility conditions
Synchronous reactive state

For example:
readonly isMenuOpen = signal(false);

toggleMenu() {
    this.isMenuOpen.update(value => !value);
}

This is a straightforward UI state and does not necessarily require an Observable.

What Is RxJS Best Used For?
RxJS is designed around reactive streams and asynchronous operations.

Enterprise Angular applications frequently need to handle:

  • HTTP requests
  • API integrations
  • Search and autocomplete
  • WebSockets
  • Event streams
  • Request cancellation
  • Retries
  • Error recovery
  • Debouncing
  • Throttling
  • Polling
  • Combining asynchronous sources

Consider an autocomplete feature.
A user types a search term, and the application needs to wait briefly, ignore duplicate values, cancel an outdated request, and execute the latest request.

RxJS provides operators for this type of workflow:
searchTerms$
    .pipe(
        debounceTime(300),
        distinctUntilChanged(),
        switchMap(term => this.searchService.search(term))
    );

Here, debounceTime, distinctUntilChanged, and switchMap help express the asynchronous behavior clearly.

This is one of the areas where RxJS continues to be extremely useful.

Signals and RxJS Can Work Together
One of the biggest misconceptions is that adopting Signals means removing RxJS.

In a real enterprise application, both can work together.

A common architecture might look like this:
API / Events
     ↓
    RxJS
     ↓
Application State
     ↓
  Signals
     ↓
    UI

For example, an Angular service might continue returning an Observable:
getUsers(): Observable<User[]> {
    return this.http.get<User[]>('/api/users');
}

The component can then use Signals for UI-facing state:
readonly users = signal<User[]>([]);
readonly loading = signal(false);

loadUsers() {
    this.loading.set(true);

    this.userService.getUsers().subscribe({
        next: users => {
            this.users.set(users);
            this.loading.set(false);
        },
        error: () => {
            this.loading.set(false);
        }
    });
}

The important point is not that every application should use this exact implementation.

The architectural idea is that RxJS can manage asynchronous data flow while Signals represent state consumed by the UI.

When Should You Use Signals?
A practical guideline is to consider Signals when you're working with:

1. Component State
State that belongs directly to a component can often be represented cleanly with Signals.

2. Derived State
Computed values are a natural use case for Signals.
const price = signal(100);
const quantity = signal(3);

const total = computed(() => price() * quantity());

3. UI Interactions
Signals work well for:

  • Menus
  • Tabs
  • Filters
  • Toggles
  • Selected items
  • Visibility conditions

4. Synchronous Reactive State
If a value changes and the UI needs to react to that change immediately, Signals are often a good fit.

When Should You Use RxJS?
RxJS is a better fit when the problem involves asynchronous streams or complex event workflows.

1. API Requests
HTTP requests and backend integrations are common RxJS use cases in Angular.

2. Request Cancellation
For example, switchMap can be useful when only the latest request should remain active.

3. Complex Event Processing
When multiple events need to be combined, transformed, filtered, or coordinated, RxJS provides a rich set of operators.

4. Time-Based Operations
Operations such as:

  • Debouncing
  • Throttling
  • Delays
  • Polling
  • Timeouts

are natural RxJS use cases.

5. WebSockets and Continuous Streams
Applications that consume continuously changing data can benefit from RxJS stream-based abstractions.

Should You Replace Existing RxJS Code?
For enterprise Angular applications, there is usually no reason to migrate working RxJS code simply because Signals are newer.
Large applications may already contain:

  • HTTP pipelines
  • Shared services
  • RxJS-based state management
  • WebSocket integrations
  • Event streams
  • Custom operators
  • Complex asynchronous workflows

Rewriting all of this can introduce unnecessary risk and development effort.
A better approach is incremental adoption.
Use Signals where they make state management simpler.
Keep RxJS where asynchronous streams and event processing benefit from its capabilities.

Example: Enterprise Financial Application
Consider an enterprise financial dashboard.

The application might need to:

  • Retrieve data from multiple APIs
  • Combine asynchronous responses
  • Cancel outdated requests
  • Retry failed requests
  • Refresh data periodically
  • Apply filters
  • Calculate derived values
  • Update multiple UI components

RxJS can handle much of the asynchronous workflow.

Signals can represent UI-facing state such as:
selectedAccount
activeFilter
selectedDateRange
loading
dashboardData
totalValue

This separation can make the application easier to maintain.
For financial applications in particular, architectural decisions also need to consider security, scalability, integration, auditability, and long-term maintainability.