Po chwili testowania przeczytałem dokumentację i kod źródłowy 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/
Ten szczególny typ Obserwowalnych jest strumieniami o pojedynczej wartości: jeśli żądanie HTTP zakończy się powodzeniem, te obserwowalne wyemitują tylko jedną wartość, a następnie zakończą
A odpowiedź na cały problem „czy muszę się wypisać”?
To zależy.
Połączenie HTTP Nieszczelności pamięci nie stanowią problemu. Problemy dotyczą logiki funkcji zwrotnych.
Na przykład: Routing lub Login.
Jeśli Twoje połączenie jest logowaniem, nie musisz „anulować subskrypcji”, ale musisz się upewnić, że jeśli użytkownik opuści stronę, odpowiednio zareagujesz na nieobecność użytkownika.
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');
})
Od irytujących po niebezpieczne
Teraz wyobraź sobie, że sieć działa wolniej niż zwykle, połączenie trwa dłużej 5 sekund, a użytkownik opuszcza widok logowania i przechodzi do „widoku wsparcia”.
Składnik może nie być aktywny, ale subskrypcja. W przypadku odpowiedzi użytkownik zostanie nagle przekierowany (w zależności od implementacji handleResponse ()).
To nie jest dobre.
Wyobraź sobie również, że użytkownik opuszcza komputer, wierząc, że nie jest jeszcze zalogowany. Ale logika loguje użytkownika, teraz masz problem z bezpieczeństwem.
Co możesz zrobić BEZ rezygnacji z subskrypcji?
Uzależnij połączenie od aktualnego stanu widoku:
public isActive = false;
public ngOnInit(): void {
this.isActive = true;
}
public ngOnDestroy(): void {
this.isActive = false;
}
Użytkownik, .pipe(takeWhile(value => this.isActive))aby upewnić się, że odpowiedź jest obsługiwana tylko wtedy, gdy widok jest aktywny.
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');
})
Ale skąd masz pewność, że subskrypcja nie powoduje wycieków pamięci?
Możesz się zalogować, jeśli zastosowano „teardownLogic”.
TeardownLogic subskrypcji zostanie wywołany, gdy subskrypcja będzie pusta lub anulowana.
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');
});
Nie musisz rezygnować z subskrypcji. Powinieneś wiedzieć, czy w Twojej logice występują problemy, które mogą powodować problemy z subskrypcją. I zaopiekuj się nimi. W większości przypadków nie będzie to problemem, ale szczególnie przy krytycznych zadaniach, takich jak autoryzacja, powinieneś zadbać o nieoczekiwane zachowanie, zastępując je „anulowaniem subskrypcji” lub inną logiką, taką jak piping lub warunkowe funkcje zwrotne.
dlaczego nie zawsze zrezygnować z subskrypcji?
Wyobraź sobie, że składasz żądanie sprzedaży lub postu Serwer odbiera wiadomość w obu kierunkach, tylko odpowiedź trwa chwilę. Anulowanie subskrypcji nie spowoduje cofnięcia postu ani umieszczenia. Ale gdy anulujesz subskrypcję, nie będziesz mieć możliwości obsłużenia odpowiedzi lub poinformowania użytkownika, na przykład za pomocą okna dialogowego lub wiadomości / wiadomości itp.
Co powoduje, że Użytkownik uważa, że żądanie umieszczenia / wysłania nie zostało wykonane.
Więc to zależy. To Twoja decyzja projektowa, jak poradzić sobie z takimi problemami.
