После некоторого времени тестирования, чтения документации и исходного кода HttpClient.
HttpClient:
https://github.com/angular/angular/blob/master/packages/common/http/src/client.ts
HttpXhrBackend :
https://github.com/angular/angular/blob/master/packages/common/http/src/xhr.ts
HttpClientModule
: https://indepth.dev/exploring-the-httpclientmodule-in-angular/
Угловой университет: https://blog.angular-university.io/angular-http/
Этот конкретный тип наблюдаемых является потоками с одним значением: если HTTP-запрос успешен, эти наблюдаемые будут выдавать только одно значение, а затем завершаться.
И ответ на весь вопрос "нужно ли мне" отписаться?
Это зависит.
Http вызов Memoryleaks не проблема. Проблемы - логика в ваших функциях обратного вызова.
Например: Маршрутизация или Логин.
Если ваш звонок является входящим вызовом, вам не нужно «отписываться», но вы должны убедиться, что если пользователь покидает страницу, вы правильно обрабатываете ответ в отсутствие пользователя.
this.authorisationService
.authorize(data.username, data.password)
.subscribe((res: HttpResponse<object>) => {
this.handleLoginResponse(res);
},
(error: HttpErrorResponse) => {
this.messageService.error('Authentication failed');
},
() => {
this.messageService.info('Login has completed');
})
От раздражающего к опасному
А теперь представьте, что сеть медленнее, чем обычно, вызов занимает больше 5 секунд, и пользователь покидает окно входа в систему и переходит в «представление поддержки».
Компонент может быть не активным, но подписка. В случае ответа пользователь будет внезапно перенаправлен (в зависимости от вашей реализации handleResponse ()).
Это не хорошо
Также представьте, что пользователь покидает компьютер, полагая, что он еще не вошел в систему. Но вы логически входите в систему пользователя, теперь у вас есть проблемы с безопасностью.
Что можно сделать БЕЗ отписки?
Звонок зависит от текущего состояния просмотра:
public isActive = false;
public ngOnInit(): void {
this.isActive = true;
}
public ngOnDestroy(): void {
this.isActive = false;
}
Пользователь .pipe(takeWhile(value => this.isActive))
должен убедиться, что ответ обрабатывается только при активном представлении.
this.authorisationService
.authorize(data.username, data.password).pipe(takeWhile(value => this.isActive))
.subscribe((res: HttpResponse<object>) => {
this.handleLoginResponse(res);
},
(error: HttpErrorResponse) => {
this.messageService.error('Authentication failed');
},
() => {
this.messageService.info('Login has completed');
})
Но как вы можете быть уверены, что подписка не вызывает утечек памяти?
Вы можете войти, если применяется teardownLogic.
TeardownLogic подписки вызывается, когда подписка пуста или отписана.
this.authorisationService
.authorize(data.username, data.password).pipe(takeWhile(value => this.isActive))
.subscribe((res: HttpResponse<object>) => {
this.handleLoginResponse(res);
},
(error: HttpErrorResponse) => {
this.messageService.error('Authentication failed');
},
() => {
this.messageService.info('Login has completed');
}).add(() => {
// this is the teardown function
// will be called in the end
this.messageService.info('Teardown');
});
Вам не нужно отписываться. Вы должны знать, есть ли проблемы в вашей логике, которые могут вызвать проблемы в вашей подписке. И позаботься о них. В большинстве случаев это не будет проблемой, но особенно в критических задачах, таких как авторизация, вы должны позаботиться о непредвиденном поведении, помешать его «отписаться» или другой логике, такой как конвейер или функции условного обратного вызова.
почему просто не всегда отписаться?
Представьте, что вы делаете запрос на размещение или публикацию. Сервер получает сообщение в любом случае, только ответ занимает некоторое время. Отписаться, не отменить сообщение или положить. Но когда вы отмените подписку, у вас не будет возможности обработать ответ или проинформировать пользователя, например, через диалог, тост / сообщение и т. Д.
Это заставляет Пользователя полагать, что запрос на размещение / публикацию не был выполнен.
Так что это зависит. Это ваше дизайнерское решение, как бороться с такими проблемами.