A subscription represents an active connection to an observable and the execution associated with receiving its notifications. Losing the observable reference does not stop that execution: a subscription can become a “zombie” subscription, continuing work after a page or component no longer needs it. section 5.3.1
Manage subscriptions through either the subscription object or the observable pipeline:
- Store the object returned by subscribe and call unsubscribe() to terminate that particular subscription. section 5.3.2
- For multiple component subscriptions, prefer a lifecycle-aware pipeline such as takeUntil with a destroy$ Subject, triggered from ngOnDestroy. section 5.3.2
- Treat cleanup as a user-experience and resource concern: routed components that retain subscriptions can accumulate memory leaks or continue connections unnecessarily. section 5.3.1
Stopping an interval
const subscription = interval(1_000).subscribe(console.log); subscription.unsubscribe(); The explicit handle is simple, but a component with many subscriptions can become cluttered; a shared lifecycle signal such as takeUntil(this.destroy$) centralizes termination. section 5.3.2
let obs$ = interval(1_000); obs$.subscribe(console.log); obs$ = null;
Inspect the minimal zombie-subscription example: assigning null to the observable reference does not terminate the active interval subscription. section 5.3.1
Signal interop does not eliminate lifecycle concerns. toSignal subscribes to its observable, so a service-backed socket may remain open after consuming components disappear. Explicit connection and cleanup design can keep such shared resources bounded. section 7.3.3
