Below is a simple example of what I am asking about:
class AppComponent {
someInput: FormControl = new FormControl('');
private subscription: Subscription;
constructor(){
this.subscription = this.someInput.valueChanges
.subscribe(() => console.log("testing"));
}
}
I have 2 questions:
1) Do I have to eventually unsubscribe from this? 2) Most importantly, whatever the answer is to #1, WHY is that the answer?
Any insight would be appreciated!
Thanks!
UPDATE OCT 2020
This question gets a lot of SEO traffic and whilst my answer is still technically correct, I strongly advise you to read this.
Yes, you do. Note that you do not need to unsubscribe from http calls because they auto-complete themselves.
You must unsubscribe to prevent memory leaks and to avoid unexpected side-effects in your application.
For example, when a component is destroyed, the subscription will remain if you don't unsubscribe from it. The next time the user navigates back to that page and the component gets loaded again, it will create another subscription to valueChanges - now you have 2 active subscriptions processing data simultaneously and that will lead to unexpected behavior in your app.
There is a relatively easy way to setup auto-unsubscribing.
The RxJS way is to use takeUntil - it basically lets you set up a subscriber which keeps listening UNTIL you tell it not to :)
First we need a destroy subject in our component:
private destroy$ = new Subject();
Then tell it to emit a value when our component is destroyed:
ngOnDestroy(){
this.destroy$.next();
this.destroy$.complete();
}
Now setup your subscribes to use it:
this.someInput.valueChanges
.debounceTime(1000)
.distinctUntilChanged()
.takeUntil(this.destroy$)
.subscribe (newValue => {
All the subscribes setup like this will then auto-unsubscribe when they receive the destroy notification.
This is especially useful if, for example, you have an ngFor that is dynamically adding controls, and each control added has a valueChanges subscription (eg. an array of controls). In such a scenario you don't need to loop through the array in ngOnDestroy and unsubscribe one-by-one. Just use takeUntil :)
I recommend reading Ben Lesh's article (RxJS lead engineer at Google) for a great overview of takeUntil, including pros/cons.
someInput object and in turn its' valueChanges observable instance and the subscription function, so they should be eligible for gc as well. So why would you have a memory leak? Does rxjs keep references to the subscription functions in some state outside the Observable instance? That sounds unlikely to me but I'm not familiar with the inner workings of rxjs. I see the problem when using interval or similar but not in this case.
.debounceTime(1000) and .distinctUntilChanged() part of the answer? The linked example doesn't add those, but it adds other piped function calls that the OP didn't have, so I'm confused on what is actually required.I highly recommend the rxjs extension https://github.com/ngneat/until-destroy . It will help you write less code.
@UntilDestroy()
@Component({})
export class InboxComponent {
ngOnInit() {
this.someInput.valueChanges
.pipe(untilDestroyed(this))
.subscribe();
}
}
For thing whatever subscribe, you need to unsubscribe to prevent memory leak. There are a few way to unsubscribe.
a. "auto unsubscribe after N time" - add .take(numberOfTimes) will unsubscribe after the N time you specified. For example:
this.subscription = this.someInput.valueChanges
.take(2) // unsubscribe after 2 times
.subscribe(() => console.log("testing"));
b. Unsubscribe during component lifecycle manually, normally during ngOnDestroy()
Yes we need to unsubscribe valueChanges subscription to prevent memory leaks. You can check simply check demo here
You don't have to. I've created a stackblitz and a video proving that observable subscription doesn't always need to be unsubscribed eventhough it doesn't complete.
This video shows how I did the memory profiling.
This is the stackblitz project:
