Angular Signals and RxJS: Give Each Tool a Clear Job
Use signals for synchronous application state and RxJS for asynchronous streams without forcing either tool into every problem.
Signals and RxJS overlap enough to create confusion, but they are strongest in different situations. A practical application does not need to choose one winner. It needs clear rules for where each belongs.
Signals are well suited to current synchronous state: a selected tab, filter values, an expanded panel, or data already held by a service. Computed signals describe values derived from that state and keep that relationship visible without manual synchronization.
RxJS remains valuable for events that unfold over time: HTTP requests, route changes, debounced search input, retries, cancellation, and combinations of asynchronous sources. Its operators express timing and concurrency more directly than a chain of effects.
Avoid copying values repeatedly between the two systems. Convert at a boundary when necessary, then let the receiving side own the representation. An observable returned by a data service can feed a signal used by the view, while an event stream can remain an observable throughout its asynchronous workflow.
Effects should perform genuine side effects rather than quietly maintaining derived state that could be computed. Whichever tool you use, keep ownership obvious and cleanup automatic. Reactive code is successful when another developer can identify the source, transformation, and destination of a value without reconstructing a hidden chain of updates.
