Après un certain temps de test, lecture de la documentation et du code source du 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/
Université angulaire: https://blog.angular-university.io/angular-http/
Ce type particulier d'Observables sont des flux à valeur unique: si la requête HTTP aboutit, ces observables n'émettront qu'une seule valeur puis se termineront
Et la réponse à toute la question de "ai-je besoin" de me désinscrire?
Ça dépend.
Les fuites de mémoire des appels HTTP ne sont pas un problème. Les problèmes sont la logique de vos fonctions de rappel.
Par exemple: routage ou connexion.
Si votre appel est un appel de connexion, vous n'avez pas à vous "désinscrire" mais vous devez vous assurer que si l'utilisateur quitte la page, vous gérez la réponse correctement en l'absence de l'utilisateur.
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');
})
D'ennuyeux à dangereux
Imaginez maintenant, le réseau est plus lent que d'habitude, l'appel prend plus de 5 secondes et l'utilisateur quitte la vue de connexion et passe à une "vue de support".
Le composant n'est peut-être pas actif mais l'abonnement. En cas de réponse, l'utilisateur sera soudainement redirigé (selon votre implémentation de handleResponse ()).
Ce n'est pas bon.
Imaginez également que l'utilisateur quitte le PC, croyant qu'il n'est pas encore connecté. Mais votre logique connecte l'utilisateur, vous avez maintenant un problème de sécurité.
Que pouvez-vous faire SANS vous désinscrire?
Rendre votre appel dépendant de l'état actuel de la vue:
public isActive = false;
public ngOnInit(): void {
this.isActive = true;
}
public ngOnDestroy(): void {
this.isActive = false;
}
L'utilisateur .pipe(takeWhile(value => this.isActive))
doit s'assurer que la réponse n'est gérée que lorsque la vue est active.
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');
})
Mais comment être sûr que l'abonnement ne cause pas de fuites de mémoire?
Vous pouvez vous connecter si le "teardownLogic" est appliqué.
La déchirureLogic d'un abonnement sera appelée lorsque l'abonnement est vide ou non souscrit.
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');
});
Vous n'êtes pas obligé de vous désinscrire. Vous devez savoir s'il y a des problèmes dans votre logique, qui pourraient causer des problèmes dans votre abonnement. Et prends soin d'eux. Dans la plupart des cas, ce ne sera pas un problème, mais surtout pour les tâches critiques telles que l'autorisation, vous devez faire attention aux comportements inattendus, que ce soit avec "unsubscribe" ou une autre logique comme la tuyauterie ou les fonctions de rappel conditionnel.
pourquoi ne pas simplement toujours vous désinscrire?
Imaginez que vous fassiez une demande de vente ou de publication. Le serveur reçoit le message de toute façon, la réponse prend un certain temps. Se désinscrire, n'annulera pas le message ni ne le mettra. Mais lorsque vous vous désabonnez, vous n'aurez pas la possibilité de gérer la réponse ou d'informer l'utilisateur, par exemple via une boîte de dialogue ou un toast / message, etc.
Ce qui fait croire à l'utilisateur que la demande put / post n'a pas été effectuée.
Cela dépend donc. C'est votre décision de conception, comment traiter ces problèmes.