RxJS, Signals, and Native Observables: Answering the Critical Questions

RxJS, Signals, and now Native Observables - Angular developers are currently facing a paradox of choice. The move toward "optional RxJS" has sparked debate, confusion, and excitement. To cut through the noise, this session is structured around seven guiding questions that tell the story of Angular's reactive future.
We will explore:
- The Context: How did the shift to Signals and optional RxJS happen, and why didn't we just stick to RxJS?
- The Friction: Why is RxJS perceived as difficult, and how can we simplify our usage of it today?
- The Strategy: When exactly should you use Signals, and when are Observables still superior?
- The Horizon: Will Native Observables change the game again, and what does the future likely hold?

Transcript

1. RxJS, Signals & Native Observables Answering the Critical Questions RainerHahnekamp
2. About Me... https://www.youtube.com/ @RainerHahnekamp https://www.ng-news.com • Rainer Hahnekamp • ANGULARarchitects.io • NgRx Core Team • Developer / Trainer / Speaker @RainerHahnekamp Open Source Projects NgRx Toolkit Testronaut NgRx Sheriff
3. RainerHahnekamp "Angular should become easier." "Signals are easier than RxJS." "You will require both."
4. RainerHahnekamp "Angular should become easier." "Signals are easier than RxJS." "You will require both." 🫤
5. RainerHahnekamp "Angular should become easier." "Signals are easier than RxJS." "You will require both." 🫤
6. RainerHahnekamp Why RxJS doesn't go away • Existing Code • Knowledge among Developers • Native Observables • Superior Race Condition Management
7. RainerHahnekamp Agenda 1. How did Signals/optional RxJS happen? 2. Why not stick to RxJS? 3. Why is RxJS difficult? 4. When to use RxJS and when Signals? 5. Will Native Observables change anything? 6. How to simplify RxJS? 7. What's a potential future?
8. …long-term, we do want to move to a point where we’re making RxJs optional for Angular. Jeremy Elbourn Angular Tech Lead Angular Q&A Session 8. September 2023 https://www.youtube.com/live/yN1xIs0IucQ
9. We primarily want to remove it (RxJs) from the critical learning journey. Minko Gechev Angular Product Lead Ng-Poland 2024 https://www.youtube.com/watch?v=QtTLZRIVaKk
10. …there are probably many applications that will just fire a fetch request, get the data… you kind of give them a machinery that is more expensive to operate Pawel Koszlowski Angular Core “Future for Angular” JSParty https://changelog.com/jsparty/310
11. To clarify, we have two goals with RxJS and Angular: 1. Angular shouldn't require you to learn/use RxJS. 2. Using RxJS with Angular should feel like a natural, polished experience. Alex Rickabaugh Angular Framework Lead https://x.com/synalx/status/1844397229525913684
12. RainerHahnekamp Why not stick to RxJS?
13. RainerHahnekamp Why not stick to RxJS? • RxJS is generic • Frontend-specific requirements ◦ Pull/Push Behavior ▪ Glitch-Free ▪ Pull !== Subscription ◦ No Side-Effects ▪ resource vs HttpClient ◦ Value has to be there all the time
14. RainerHahnekamp Experiment: RxJS as Signal - Value always available import { BehaviorSubject } from 'rxjs'; // Value always available const signal = new BehaviorSubject(1); const value = signal.getValue(); // 👍
15. RainerHahnekamp Experiment: RxJS as Signal - Glitch-Free const signal = new BehaviorSubject(1).pipe( debounceTime(0), ) as BehaviorSubject<number>; // 🤔 signal.subscribe(console.log); signal.next(2); signal.next(3);
16. RainerHahnekamp Experiment: RxJS as Signal - No Side-Effects • Just use BehaviorSubject
17. RainerHahnekamp How to verify a specific type? type Signal<T> = new BehaviorSubject(1).pipe(debounceTime(0)) as BehaviorSubject<number>; 👎 const SIGNAL = Symbol('SIGNAL'); type Signal<T> = BehaviorSubject<T> & {[SIGNAL]: true} function createSignal<T>(initialValue: T): Signal<T> { const signal = new BehaviorSubject(initialValue); (signal as any)[SIGNAL] = true return signal; }
18. RainerHahnekamp How to verify that all pipes are Signal?
19. RainerHahnekamp Why is RxJS difficult?
20. RainerHahnekamp "Problem Fields" • Subscription Management • Multicasting • Error Behavior • Asynchronous & Synchronous Tasks • Incompatibility with Non-Streaming Behavior ◦ HTTP Requests
21. RainerHahnekamp When to choose Signals and when RxJS?
22. RainerHahnekamp a b c d e State Events (Observables, Callbacks) "Event-based" Change Detection / Synchronization (zone.js)
23. RainerHahnekamp a b c d e State (Signals) Events (Observables, Callbacks) "State-based" Change Detection / Synchronization (Signals)
24. RainerHahnekamp Component Tree DOM Submit Cancel zone.js Handled DOM Events Asynchronous Tasks Change Detection with zone.js
25. RainerHahnekamp Component Tree DOM Submit Cancel Change Detection without zone.js (zoneless) async Pipe Signal Change Handled DOM Event Immutable Property Binding manually run markForCheck()
26. RainerHahnekamp Component Tree DOM Submit Cancel Future Change Detection Signal Components Signal Change
27. RainerHahnekamp Signals • Represents State ◦ Value is always available ◦ Glitch-Free RxJS • Represents Events ◦ Time plays a central role ◦ Race Condition Management
28. RainerHahnekamp a b c d e State (BehaviorSubject) Events (Observables, Callbacks) Old Way of managing State
29. RainerHahnekamp Signals • Represents State ◦ Value is always available ◦ Glitch-Free RxJS • Represents Events ◦ Time plays a central role ◦ Race Condition Management BehaviorSubject as intersection
30. RainerHahnekamp Signals • Represents State ◦ Value is always available ◦ Glitch-Free RxJS • Represents Events ◦ Time plays a central role ◦ Race Condition Management BehaviorSubject as intersection
31. RainerHahnekamp • You MUST use Signals for state • You CAN use RxJS for events
32. RainerHahnekamp It is not RxJS vs. Signals. It is RxJS vs. event callbacks
33. RainerHahnekamp Is it really that easy? Signal Change = Event
34. RainerHahnekamp a b c d e State (Signals) Events (Observables, Callbacks) "State-based" Change Detection / Synchronization (Signals) x y z Debouncing of Form Fields Signals
35. RainerHahnekamp API Challenges Is it really that easy? Signal Change = Event
36. RainerHahnekamp Will Native Observables change anything?
37. RainerHahnekamp How to make RxJS easier?
38. RainerHahnekamp What's a potential future?
39. RainerHahnekamp Where RxJS Shines… Pipe Operators Managing Race Conditions
40. RainerHahnekamp Three Levels of RxJS Usage 1. No RxJS a. For very simple applications b. Self-written pipe operators (debounceTime)
41. RainerHahnekamp Three Levels of RxJS Usage 1. No RxJS a. For very simple applications b. Self-written pipe operators (debounceTime) 2. Embedded RxJS a. Library, Functions manage subscriptions automatically b. Users just need to apply pipe operators c. SignalStore, ngxtension,...
42. RainerHahnekamp Three Levels of RxJS Usage 1. No RxJS a. For very simple applications b. Self-written pipe operators (debounceTime) 2. Embedded RxJS a. Library, Functions manage subscriptions automatically b. Users just need to apply pipe operators c. SignalStore, ngxtension,... 3. All-In RxJS a. Event-Driver Apps b. Dashboards, Monitoring,...
43. RainerHahnekamp Three Levels of RxJS Usage 1. No RxJS a. For very simple applications b. Self-written pipe operators (debounceTime) 2. Embedded RxJS a. Library, Functions manage subscriptions automatically b. Users just need to apply pipe operators c. SignalStore, ngxtension,... 3. All-In RxJS a. Event-Driver Apps b. Dashboards, Monitoring,...
44. RainerHahnekamp Summary • Use Signals whenever you can • Don't use BehaviorSubject • Don't use RxJS because just because it is an event • Make use of utility functions ◦ RxJS in a controlled manner • Signals will incorporate common RxJS use cases ◦ switchMap in resource's loader ◦ exhaustMap in resource's reload() ◦ debounce in SignalForms