Depois de um tempo de teste, a leitura da documentação e o código fonte do 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/
Universidade Angular: https://blog.angular-university.io/angular-http/
Esse tipo específico de Observáveis são fluxos de valor único: se a solicitação HTTP for bem-sucedida, esses observáveis emitirão apenas um valor e, em seguida, serão concluídos.
E a resposta para toda a edição de "eu preciso" cancelar a inscrição?
Depende.
Chamada HTTP Memoryleaks não é um problema. Os problemas são a lógica nas suas funções de retorno de chamada.
Por exemplo: Roteamento ou Login.
Se a sua ligação for de login, você não precisará "cancelar a inscrição", mas precisará garantir que, se o Usuário sair da página, lide com a resposta adequadamente na ausência do usuário.
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');
})
De irritante a perigoso
Agora, imagine, a rede está mais lenta que o normal, a chamada leva mais 5 segundos e o usuário sai da visualização de login e passa para uma "visualização de suporte".
O componente pode não estar ativo, mas a assinatura. No caso de uma resposta, o usuário será redirecionado repentinamente (dependendo da sua implementação handleResponse ()).
Isso não é bom.
Imagine também que o usuário saia do PC, acreditando que ainda não está logado. Mas você lógico faz logon no usuário, agora você tem um problema de segurança.
O que você pode fazer SEM cancelar a inscrição?
Faça sua ligação dependente do estado atual da exibição:
public isActive = false;
public ngOnInit(): void {
this.isActive = true;
}
public ngOnDestroy(): void {
this.isActive = false;
}
Usuário .pipe(takeWhile(value => this.isActive))para garantir que a resposta seja tratada apenas quando a exibição estiver ativa.
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');
})
Mas como você pode ter certeza de que a assinatura não está causando falta de memória?
Você pode registrar se o "teardownLogic" for aplicado.
O teardownLogic de uma assinatura será chamado quando a subscrição estiver vazia ou sem assinatura.
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');
});
Você não precisa cancelar a inscrição. Você deve saber se há problemas em sua lógica que podem causar problemas em sua assinatura. E cuide deles. Na maioria dos casos, isso não será um problema, mas principalmente em tarefas críticas como a autorização, você deve cuidar de um comportamento inesperado, seja com "cancelamento de inscrição" ou com outra lógica, como funções de canal ou retorno de chamada condicional.
por que não sempre cancelar a inscrição?
Imagine que você faça uma solicitação de colocação ou publicação. O servidor recebe a mensagem de qualquer maneira, apenas a resposta demora um pouco. Cancelar a inscrição, não desfará a postagem nem a coloca. Porém, ao cancelar a inscrição, você não terá a chance de lidar com a resposta ou informar o Usuário, por exemplo, via Caixa de Diálogo ou um Toast / Message etc.
O que faz com que o usuário acredite que a solicitação de put / post não foi feita.
Então depende. É sua decisão de design, como lidar com esses problemas.
