如果您想了解更多关于拦截器和 HttpClientModule 如何在后台工作的信息，可以查看这篇文章：在 Angular 中探索 HttpClientModule。
我的方法有缺陷吗？在这种情况下，问题在于next.handle预期会返回一个 Observable，但通过订阅它，它会返回一个 Subscription。
为了更好地理解原因，我将粘贴从上面链接的文章中复制的片段：
const obsBE$ = new Observable(obs => {
timer(1000)
.subscribe(() => {
// console.log('%c [OBSERVABLE]', 'color: red;');
obs.next({ response: { data: ['foo', 'bar'] } });
// Stop receiving values!
obs.complete();
})
return () => {
console.warn("I've had enough values!");
}
});
// Composing interceptors the chain
const obsI1$ = obsBE$
.pipe(
tap(() => console.log('%c [i1]', 'color: blue;')),
map(r => ({ ...r, i1: 'intercepted by i1!' }))
);
let retryCnt = 0;
const obsI2$ = obsI1$
.pipe(
tap(() => console.log('%c [i2]', 'color: green;')),
map(r => {
if (++retryCnt <=3) {
throw new Error('err!')
}
return r;
}),
catchError((err, caught) => {
return getRefreshToken()
.pipe(
switchMap(() => /* obsI2$ */caught),
)
})
);
const obsI3$ = obsI2$
.pipe(
tap(() => console.log('%c [i3]', 'color: orange;')),
map(r => ({ ...r, i3: 'intercepted by i3!' }))
);
function getRefreshToken () {
return timer(1500)
.pipe(q
map(() => ({ token: 'TOKEN HERE' })),
);
}
function get () {
return obsI3$
}
get()
.subscribe(console.log)
/*
-->
[i1]
[i2]
I've had enough values!
[i1]
[i2]
I've had enough values!
[i1]
[i2]
I've had enough values!
[i1]
[i2]
[i3]
{
"response": {
"data": [
"foo",
"bar"
]
},
"i1": "intercepted by i1!",
"i3": "intercepted by i3!"
}
I've had enough values!
*/
StackBlitz 演示。
要点是拦截器创建某种链，该链以负责发出实际请求的可观察对象结束。这是链中的最后一个节点：
return new Observable((observer: Observer<HttpEvent<any>>) => {
// Start by setting up the XHR object with request method, URL, and withCredentials flag.
const xhr = this.xhrFactory.build();
xhr.open(req.method, req.urlWithParams);
if (!!req.withCredentials) {
xhr.withCredentials = true;
}
/* ... */
})
如何在 http 拦截器上返回一个 observable 并同时维护一个队列
我认为解决此问题的一种方法是创建一个包含队列逻辑并使其intercept方法返回的拦截器Observable，以便可以订阅它：
const queueSubject = new Subject<Observable>();
const pendingQueue$ = queueSubject.pipe(
// using `mergeAll` because the Subject's `values` are Observables
mergeAll(limit),
share(),
);
intercept (req, next) {
// `next.handle(req)` - it's fine to do this, no request will fire until the observable is subscribed
queueSubject.next(
next.handle(req)
.pipe(
// not interested in `Sent` events
filter(ev => ev instanceof HttpResponse),
filter(resp => resp.url === req.url),
)
);
return pendingQueue$;
}
使用filter运算符是因为通过 using share，响应将发送给所有订阅者。想象一下，你同步调用http.get了 5 次，所以 5 个新订阅者为share' 的主题，最后一个将收到它的响应，但其他请求的响应也是如此。因此使用可以filter为请求提供正确的响应，在这种情况下，通过将 request( req.url) 的 URL 与我们从 获得的 URL进行比较HttpResponse.url：
observer.next(new HttpResponse({
body,
headers,
status,
statusText,
url: url || undefined,
}));
上述代码段的链接。
现在，我们为什么使用share()?
我们先看一个更简单的例子：
const s = new Subject();
const queue$ = s.pipe(
mergeAll()
)
function intercept (req) {
s.next(of(req));
return queue$
}
// making request 1
intercept({ url: 'req 1' }).subscribe();
// making request 2
intercept({ url: 'req 2' }).subscribe();
// making request 3
intercept({ url: 'req 3' }).subscribe();
此时，主题s应该有 3 个订阅者。这是因为当您返回队列时，您会返回s.pipe(...)，当您订阅它时，它与执行以下操作相同：
s.pipe(/* ... */).subscribe()
所以，这就是主题最后会有 3 个订阅者的原因。
现在让我们检查相同的代码段，但使用share()：
const queue$ = s.pipe(
mergeAll(),
share()
);
// making request 1
intercept({ url: 'req 1' }).subscribe();
// making request 2
intercept({ url: 'req 2' }).subscribe();
// making request 3
intercept({ url: 'req 3' }).subscribe();
订阅请求 1 后，share将创建一个 Subject 实例，所有后续订阅者都将属于它，而不是属于主Subject s。因此，s将只有一个订阅者。这将确保我们正确实现队列，因为尽管 Subjects只有一个订阅者，但它仍然会接受s.next()值，其结果将传递给另一个主题（来自 的那个share()），最终将发送响应给它的所有订阅者。