Introduction of signals has stirred quite a storm in angular developer community (and outside as well). And quite rightly so. Lets see why is there so much hype around it

Advantages of Signals

Performance

With signals, angular applications can have fine-grained reactivity. Which means only the DOM nodes which needs to be updated will be updated. This can potentially make angular application very efficient about its DOM updates and change detection. In contrast, currently in angular whole tree goes through dirty checking because the framework doesn’t know which part of the DOM depends on which part of the view model.

Also, with signals we can finally have zone-less application, as framework will get notification for any changes happening in the view model which uses signals.

Even in current version of angular without signals we can still get highly performant application, but signals will make it hard to shot ourself in the foot and accidentally create performance related issues.

Developer doesn’t need to worry about which changeDetectionStrategy to use, or calling functions is template, or memoize functions or using pipes. All these best practices to build performant app might become irrelevant. Less thing to learn is always good thing

Developer Ergonomics

Any moderate to complex angular applications has a lot of rxjs usages. Though rxjs is a very useful library, it might not be easy to grasp for lot of developers. To create a reactive applications, and handle race conditions rxjs becomes essential. Cant live with it, cant leave without it.

But with signals we can potentially get rid of most of rxjs code. This will make angular much more welcoming to new developers and increase overall readability of the code base.

Distinction between rxjs and signals

While going through example usages of signals, lot of developers might feels is just rxjs with different apis. The similarity is uncanny, especially with BehaviourSubject

//Example behaviourSubject usage
const subject = new BehaviourSubject(0);
subject.getValue();
subject.next(1);
subject.subscribe((data) => {
  console.log(data)
})

//Example signal usage
const sig = signal(0);
sig()
sig.set(1)
effect(() => {
  console.log(sig())
})

But once we dig in a little bit the distinction starts getting more clear.

Signals are always sync. Hence you can always get current value of a signal. But Observable is not always sync. It may be sync or async, we cant say for certain. It’s very straightforward to get current value of signal but not so much for Observable . With BehaviourSubject sure we can always get current value in sync, but once we do any kind of operation, we loose that capability.

const number = new BehaviourSubject(0);
number.getValue();
const isOdd = number.pipe(map((data) => data % 2 ? true : false));
isOdd.getValue() //<--- we can not do this

const numberSignal = new BehaviourSubject(0);
numberSignal();
const isOddSignal = computed(() => numberSignal() % 2 ? true : false);
isOddSignal() //<--- we can do this

Also signal do not require distinctUntilChange or shareReplay for multicasting, unlike Observable in most cases.

Then we don’t need rxjs?

Well, not exactly. Because signal is always sync. They are very good candidate for storing states or view model. But signals are not very good candidate for async stuff, like events, or XHR calls. For those we would still need rxjs, mostly.

Classic example is search-as-you-type usecase, where we leverage, debounceTime distinctUntilChanges and switchMap

const searchValue$: Observable<string> //lets assume this is comes from input
const result$ = searchValue$.pipe(
  debounceTime(300),
  distinctUntilChanged(),
  switchMap((input) => {
    return this.http.get('/seach?' + input)
  })
)

For converting this to use signals, we might jump from signal to observable then back to signals

const searchValue: Signal<string>
const searchValue$ = fromSignal(searchValue); //convert signal to observable
const result$ = searchValue$.pipe(
  debounceTime(300),
  distinctUntilChanged(),
  switchMap((input) => {
    return this.http.get('/seach?' + input)
  })
)
const result = fromObservable(result$) //convert observable back to signal

In a world where signals are adopted completely we might see rxjs used sparingly only for such use case. It’s little awkward to keep jumping between signal and rxjs way of writing code. But maybe we can remove rxjs completely even for such cases?

const searchValue: Signal<string>
const debouncedSearchValue = signal(searchValue());
const results: WritableSignal<Result[]> = signal([])
/**
* This effect add debounced search term in a new signal
*/
effect(() => {
  const search = searchValue();
  const timeout = setTimeout(() => {
    debouncedSearchValue.set(search)
  });
  return () => {
    clearTimeout(timeout)
  }
})
/**
* This effect uses debounceSearchValue instead of searchValue
* to trigger api call
*/
effect(() => {
  const subscription = this.http.get('/seach?' + debouncedSearchValue())
  .subscribe((res) => {
    results.set(res)
  })
  return () => {
    subscription.unsubscribe()
  }
})

If you are comparing the code with and without rxjs, ofcourse, the one using rxjs looks much more concise. Let’s refactor it a little bit to make it more concise.

const searchValue: Signal<string>
const debounceSearchValue = debouncedSignal(searchValue);
const results: WritableSignal<Result[]> = signal([]);
effect(() => {
  const subscription = this.http.get('/seach?' + debouncedSearchValue())
  .subscribe((res) => {
    results.set(res)
  })
  return () => {
    subscription.unsubscribe()
  }
})

This looks better. Still less concise than rxjs one, but we don’t need to learn rxjs to understand this. This is much more beginner friendly IMHO.

BTW if you are wondering debouncedSignal function used above looks like this

function debouncedSignal<T>(input: Signal<T>): Signal<T> {
  const debounceSignal = signal(input());
  effect(() => {
    const value = input();
    const timeout = setTimeout(() => {
      debounceSignal.set(value)
    });
    return () => {
      clearTimeout(timeout)
    }
  });
  return debounceSignal
}

Conclusion

Yes, signals can replace rxjs. But, maybe not completely. Even if it does, there will be some tradeoffs. rxjs brings conciseness and signals make if easier to read.

How these use-cases and patterns will evolve is something we all will see in due time and developers start exploring more. But signals are here to change how we code in angular and the hype is real