New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Http/standalone/independent #47502
Http/standalone/independent #47502
Conversation
6d980cc
to
8ba78ef
Compare
8ba78ef
to
c5bbb5b
Compare
c5bbb5b
to
e6ac0e2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alxhub looks great 👍
I've just left some cosmetic comments, but I will take another look tomorrow as well.
e6ac0e2
to
c91103d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just took another look and the changes look really great, thanks @alxhub 👍 As you mentioned, the API docs are missing atm, but we can also do that in a followup PR (anytime after feature freeze) and I'll be happy to review the docs changes once they are available.
I've left minor comments and the only question I wanted to bring up is around provideHttpClientTesting
function.
c91103d
to
56edb30
Compare
packages/common/http/src/module.ts
Outdated
@@ -156,7 +111,7 @@ export class HttpClientXsrfModule { | |||
*/ | |||
providers: [ | |||
HttpClient, | |||
{provide: HttpHandler, useClass: HttpInterceptingHandler}, | |||
{provide: HttpHandler, useClass: HttpInterceptorHandler}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: from what I understand this rename causes failures in G3 as there are applications importing this private symbol.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😠
|
||
TestBed.inject(HttpClient).get('/test', {responseType: 'text'}).subscribe(); | ||
const req = TestBed.inject(HttpTestingController).expectOne('/test'); | ||
expect(req.request.headers.get('X-Tag')).toEqual('alpha,beta'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: is this test enough to illustrate the order of "interceptor wrapping"?
I guess I would like to see something more explicit, that clearly shows how one interceptor can build on top of processing done of another interceptor (we could do this be explicitly "wrapping" a header set by one intereceptor into another string or something of this nature).
This commit introduces the main components of the `provideHttpClient()` provider API, designed in the style of `provideRouter()`. Initial features are defined for including legacy class-based interceptors, JSONP support, and configuring or disabling the builtin XSRF protection. This API is an alternative to providing `HttpClient` via the `HttpClientModule`, and is more tree-shakable and more capable than the NgModule implementation. Tests are included to validate the new configuration format as well as the interoperability of the two styles of providing and configuring `HttpClient`.
This commit converts `HttpClientModule` to use `provideHttpClient()` internally, with a particular configuration of features. Other NgModules related to configuring `HttpClient` are also converted to use the providers directly from various features, to ensure consistency of behavior.
This commit introduces a new feature for `provideHttpClient` called `withInterceptors`. This feature exposes and configures the new concept of functional interceptors. Functional interceptors use functions instead of classes to implement an HTTP interceptor. Such interceptor functions have access to the DI context from the `EnvironmentInjector` in which they're configured via the `inject()` function. Otherwise, functional interceptors are identical in capability to the existing interceptor system.
Ordinarily, providing `HttpClient` (either via `provideHttpClient` or the `HttpClientModule`) creates an entirely separate HTTP context. Requests made via that client are not passed through the interceptor chains that are configured in a parent injector, for this example. This commit introduces a new option for `provideHttpClient` called `withRequestsMadeViaParent()`. When this option is passed, requests made in the child context flow through any injectors, etc. and are then handed off to the parent context. This addresses a longstanding issue with interceptors where it's not possible to extend the set of interceptors in a child context without repeating all of the interceptors from the parent.
This commit deletes a sentence from the `HttpClientJsonpModule` docs which was accidentally copy-pasted from the docs for another symbol.
f3f4497
to
ac2c6fd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Reviewed-for: public-api
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed-for: public-api
This PR was merged into the repository by commit c09c1bb. |
This commit introduces a new DI token for the set of functional interceptors. This is a no-op in terms of behavior currently, but will allow for the deduplication of the bridge interceptor which connects legacy class- based interceptors to the functional interceptor chain. PR Close #47502
…#47502) @angular/common/http has XSRF protection which is enabled by default and is implemented as an interceptor. Previously, this protection could be disabled with an API which would internally provide a `NoopInterceptor` in place of the standard XSRF interceptor. To achieve the same capability of disabling the XSRF interceptor after it is converted to the functional style, an InjectionToken is added in this commit which disables the XSRF interceptor. This way, the interceptor can be disabled in place without needing to override it via DI (which is difficult for functional interceptors). PR Close #47502
This commit switches the XSRF configuration tokens (for header name and cookie name) to be `providedIn: 'root'`. This is a no-op change now as they are always provided along with any usage of them via `HttpClientModule`, but will become load-bearing as the `provideHttpClient` API will not provide these tokens, and will rely on injecting them from either the parent context or from these root providers. PR Close #47502
) This commit converts the XSRF interceptor into a functional interceptor instead of a legacy class-based interceptor. PR Close #47502
This commit introduces the main components of the `provideHttpClient()` provider API, designed in the style of `provideRouter()`. Initial features are defined for including legacy class-based interceptors, JSONP support, and configuring or disabling the builtin XSRF protection. This API is an alternative to providing `HttpClient` via the `HttpClientModule`, and is more tree-shakable and more capable than the NgModule implementation. Tests are included to validate the new configuration format as well as the interoperability of the two styles of providing and configuring `HttpClient`. PR Close #47502
…ly (#47502) This commit converts `HttpClientModule` to use `provideHttpClient()` internally, with a particular configuration of features. Other NgModules related to configuring `HttpClient` are also converted to use the providers directly from various features, to ensure consistency of behavior. PR Close #47502
This commit introduces a new feature for `provideHttpClient` called `withInterceptors`. This feature exposes and configures the new concept of functional interceptors. Functional interceptors use functions instead of classes to implement an HTTP interceptor. Such interceptor functions have access to the DI context from the `EnvironmentInjector` in which they're configured via the `inject()` function. Otherwise, functional interceptors are identical in capability to the existing interceptor system. PR Close #47502
) Ordinarily, providing `HttpClient` (either via `provideHttpClient` or the `HttpClientModule`) creates an entirely separate HTTP context. Requests made via that client are not passed through the interceptor chains that are configured in a parent injector, for this example. This commit introduces a new option for `provideHttpClient` called `withRequestsMadeViaParent()`. When this option is passed, requests made in the child context flow through any injectors, etc. and are then handed off to the parent context. This addresses a longstanding issue with interceptors where it's not possible to extend the set of interceptors in a child context without repeating all of the interceptors from the parent. PR Close #47502
This commit deletes a sentence from the `HttpClientJsonpModule` docs which was accidentally copy-pasted from the docs for another symbol. PR Close #47502
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
with*
feature pattern forprovideHttp
providedInRoot
fallback - it's a weird half-working state