This commit addresses dependency injection defects when using the `withFetch` API. Formerly, utilizing `withFetch` led to the automatic setting of `HttpBackend` to `FetchBackend`, which proved problematic in certain scenarios. Notably, conflicts arose when integrating `withRequestsMadeViaParent` and manually overriding tokens, as observed in instances like `InMemoryWebApiModule`.
PR Close#55652
`HttpClient` uses the `PendingTasks` service to contribute to
application stability. This was added in v16 to support SSR without
relying on an infinite `setTimeout` with ZoneJS like it did pre-v16.
Prior to version 16, this was also only done on the server and did not
affect clients or unit tests (https://github.com/angular/angular/commit/28c68f709cdc930e12bac51a266e7bf790656034).
Today, `PendingTasks` contribute to `ApplicationRef.isStable` but do not
contribute to the stability of `ComponentFixture`. This divergence in
stability behavior was not intended and we plan to make these two
stability indicators the same again, like they were when it was solely
based on the state of the Zone.
By aligning the two behaviors again, this would include all pending
tasks in the stability of fixtures. After investigation, this seems
likely to be a pretty large breaking change. Tests appear to quite often use
`await fixture.whenStable` when there are unfinished requests that have
not been mocked or flushed.
This change prevents request in `HttpClient` from contributing to
stability through the `PendingTasks` automatically but only when using
`HttpClientTesting`. In this scenario, requests need to be expected and
flushed manually for them to resolve. When the test backend and controllers
aren't used, requests should resolve on their own so `await fixture.whenStable`
shouldn't be particularly affected or problematic.
PR Close#54974
This commit adds a logic to produce a warning in case HttpClient doesn't use fetch during SSR.
It's recommended to use `fetch` for performance and compatibility reasons.
PR Close#52037
This rename reflects what the function actually does. Although the intention
is still not to have two different interceptor mechanisms, that is now
communicated in the docs for the function instead of in its name.
Fixes#47764
PR Close#47901
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 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
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
Alan Agius