Prior to this commit, we were logging the `NOT_USING_FETCH_BACKEND_IN_SSR` error when `provideHttpTestingClient` and `PLATFORM_ID` were provided.
fixes#59028
PR Close#59049
This migration will allow developers to migrate the deprecated `HttpClientModule`, `HttpClientJsonpModule` & `HttpClientXsrfModule` to their respective provider functions.
PR Close#54020
This commit deprecates the `HttpClientModule` and other related http modules. Those can be replaced by provider function only.
Angular is an opinionated framework, feature guidance will help developer choose the recommended way to enable feature (like Http requests here).
Note: This is not an indication of deprecation for `NgModule`. The deprecated module's only purpose here was to define providers. This can be done directly by the provide function pattern.
DEPRECATED: `HttpClientModule`, `HttpClientXsrfModule` and `HttpClientJsonpModule`
As mentionned, those modules can be replaced by provider function only.
PR Close#54020
`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 (28c68f709c).
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 introduces the `provideHttpClientTesting()` function as an
alternative to the `HttpClientTestingModule` (in fact, the NgModule is
converted internally to just use the new provider function).
PR Close#47502
When `HttpTestingController.verify` is used to verify that there are not open,
unexpected requests it would throw an error with the method and URL of all pending
requests, excluding the query parameters. This is confusing, as e.g. `expectOne`
matches a URL including its query parameters and `expectOne` does include the
query parameters when it reports when no request could be matched.
This commit changes the error that is reported by `verify` to include the query
parameters.
Closes#19974
PR Close#44917
Currently the `HttpClient` always wraps errors from XHR requests, but
the underlying errors are always of type `ProgressEvent`, or don't have
a native error if the status code is just indicating failure (e.g. 404).
This behavior does not match in the `TestRequest` class provided by
`@angular/common/http/testing` where errors are considered being
of type `ErrorEvent`. This is incorrect because `ErrorEvent`s provide
information for errors in scripts or files which are evaluated. Since
the `HttpClient` never evaluates scripts/files, and also since XHR requests
clearly are documented to emit `ProgressEvent`'s, we should change the
`TestSupport` to retrieve such `ProgressEvent`'s instead of incompatible
objects of type `ErrorEvent`.
In favor of having a deprecation period, we keep supporting `ErrorEvent`
in the `TestRequest.error` signature. Eventually, we can remove this
signature in the future.
Resources:
* https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/error_event
* https://developer.mozilla.org/en-US/docs/Web/API/ErrorEvent
* https://xhr.spec.whatwg.org/#event-xhr-errpr
Related to: https://github.com/angular/angular/issues/34748.
DEPRECATED: `TestRequest` from `@angular/common/http/testing` no longer
accepts `ErrorEvent` when simulating XHR errors. Instead instances of
`ProgressEvent` should be passed, matching with the native browser behavior.
PR Close#36082
Fixes#18013
Previously it was hard to debug an `expectOne` if the request had no match, as the error message was:
Expected one matching request for criteria "Match URL: /some-url?query=hello", found none.
This commit adds a bit more info to the error, by listing the actual requests received:
Expected one matching request for criteria "Match URL: /some-url?query=hello", found none. Requests received are: POST /some-url?query=world.
PR Close#27005
HttpClient is an evolution of the existing Angular HTTP API, which exists
alongside of it in a separate package, @angular/common/http. This structure
ensures that existing codebases can slowly migrate to the new API.
The new API improves significantly on the ergonomics and features of the legacy
API. A partial list of new features includes:
* Typed, synchronous response body access, including support for JSON body types
* JSON is an assumed default and no longer needs to be explicitly parsed
* Interceptors allow middleware logic to be inserted into the pipeline
* Immutable request/response objects
* Progress events for both request upload and response download
* Post-request verification & flush based testing framework
