category
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
- 登录 发表评论