经过一段时间的测试,阅读HttpClient的文档和源代码。
HttpClient: https://github.com/angular/angular/blob/master/packages/common/http/src/client.ts
a . h .出口:有何不同
HttpClientModule: https://indepth.dev/exploring-the-httpclientmodule-in-angular/
Angular大学:https://blog.angular-university.io/angular-http/
这种特殊类型的可观察对象是单值流:如果HTTP请求成功,这些可观察对象将只发出一个值,然后完成
而整个问题的答案是“我需要退订吗?”
视情况而定。
Http调用内存泄漏不是一个问题。
问题是回调函数中的逻辑。
例如:路由、登录。
如果您的呼叫是一个登录呼叫,您不必“取消订阅”,但您需要确保如果用户离开页面,您可以在用户缺席的情况下正确处理响应。
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秒,用户离开登录视图,转到“支持视图”。
组件可能不是活动的,但订阅是活动的。在响应的情况下,用户将突然被重新路由(取决于您的handlerresponse()实现)。
这可不太好。
再想象一下,用户离开了pc,认为他还没有登录。但是当用户登录时,就会出现安全问题。
如果不取消订阅,你能做什么?
使你的调用依赖于视图的当前状态:
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');
});
你不必取消订阅。
您应该知道您的逻辑中是否存在问题,这可能会导致您的订阅出现问题。照顾好他们。在大多数情况下,这不会是一个问题,但特别是在像自动化这样的关键任务中,你应该注意意外的行为,无论是“取消订阅”还是其他逻辑,如管道或条件回调函数。
为什么不总是退订呢?
假设您提出了一个put或post请求。服务器以任何一种方式接收消息,只是响应需要一段时间。取消订阅,不会撤销帖子或放。
但当您取消订阅时,您将没有机会处理响应或通知用户,例如通过对话或祝酒词/消息等。
这使得用户相信,put/post请求没有完成。
这要看情况。如何处理这些问题是你的设计决定。