Lesen Sie nach einer Weile des Testens die Dokumentation und den Quellcode des 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/
Angular Univeristy: https://blog.angular-university.io/angular-http/
Diese bestimmte Art von Observables sind einwertige Streams: Wenn die HTTP-Anforderung erfolgreich ist, geben diese Observables nur einen Wert aus und werden dann abgeschlossen
Und die Antwort auf die gesamte Ausgabe von "MUSS ich" abbestellen?
Es hängt davon ab, ob.
HTTP-Aufruf Memoryleaks sind kein Problem. Die Probleme sind die Logik in Ihren Rückruffunktionen.
Zum Beispiel: Routing oder Login.
Wenn es sich bei Ihrem Anruf um einen Anmeldeanruf handelt, müssen Sie sich nicht abmelden. Sie müssen jedoch sicherstellen, dass Sie die Antwort in Abwesenheit des Benutzers ordnungsgemäß verarbeiten, wenn der Benutzer die Seite verlässt.
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');
})
Von nervig bis gefährlich
Stellen Sie sich vor, das Netzwerk ist langsamer als gewöhnlich, der Anruf dauert länger als 5 Sekunden, und der Benutzer verlässt die Anmeldeansicht und wechselt zu einer "Support-Ansicht".
Die Komponente ist möglicherweise nicht aktiv, aber das Abonnement. Im Falle einer Antwort wird der Benutzer plötzlich umgeleitet (abhängig von Ihrer Implementierung von handleResponse ()).
Das ist nicht gut
Stellen Sie sich auch vor, der Benutzer verlässt den PC und glaubt, noch nicht angemeldet zu sein. Aber Ihre Logik meldet den Benutzer an, jetzt haben Sie ein Sicherheitsproblem.
Was können Sie tun, ohne sich abzumelden?
Machen Sie Ihren Anruf abhängig vom aktuellen Status der Ansicht:
public isActive = false;
public ngOnInit(): void {
this.isActive = true;
}
public ngOnDestroy(): void {
this.isActive = false;
}
Benutzer .pipe(takeWhile(value => this.isActive)), um sicherzustellen, dass die Antwort nur verarbeitet wird, wenn die Ansicht aktiv ist.
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');
})
Aber wie können Sie sicher sein, dass das Abonnement keine Speicherlecks verursacht?
Sie können protokollieren, wenn "teardownLogic" angewendet wird.
Die TeardownLogic eines Abonnements wird aufgerufen, wenn das Abonnement leer oder nicht abonniert ist.
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');
});
Sie müssen sich nicht abmelden. Sie sollten wissen, ob es Probleme in Ihrer Logik gibt, die Probleme in Ihrem Abonnement verursachen können. Und pass auf sie auf. In den meisten Fällen ist dies kein Problem. Insbesondere bei kritischen Aufgaben wie der Autorisierung sollten Sie sich jedoch um unerwartetes Verhalten kümmern, sei es mit "Abbestellen" oder einer anderen Logik wie Piping- oder bedingten Rückruffunktionen.
warum nicht einfach immer abbestellen?
Stellen Sie sich vor, Sie stellen eine Put- oder Post-Anfrage. Der Server empfängt die Nachricht so oder so, nur die Antwort dauert eine Weile. Wenn Sie sich abmelden, wird der Beitrag nicht rückgängig gemacht oder abgelegt. Wenn Sie sich jedoch abmelden, haben Sie nicht die Möglichkeit, die Antwort zu bearbeiten oder den Benutzer zu informieren, z. B. über einen Dialog oder einen Toast / eine Nachricht usw.
Dies lässt den Benutzer glauben, dass die Put / Post-Anfrage nicht ausgeführt wurde.
Es kommt also darauf an. Es ist Ihre Entwurfsentscheidung, wie Sie mit solchen Problemen umgehen.
