Angular 16.1 added support for using the native fetch method in the HttpClient and introduces a transform function for @Input decorator. Two new RFCs propose an alternative to the control-flow directives and deferred component loading.
Angular 16.1
fetch in HttpClient
Angular 16.1 has been released, bringing two useful new features to the framework.
The first feature allows developers to use the native fetch method instead of the older xhr object in the HttpClient. To enable this, simply use the withFetch function in the provideHttpClient configuration. This feature remains backward compatible, with the HttpClient continuing to return Observables, and all interceptors functioning as expected.
This enhancement is particularly beneficial for server-side rendering, as the XmlHttpRequest (xhr) is specific to browsers and not available on the backend. By leveraging the native fetch method, also available in Node.js, developers can avoid additional libraries.
Matthieu Riegler, a community contributor, deserves recognition for implementing this feature. Since late 2022, Matthieu has made over 200 commits to the Angular repository.
feat(http): Introduction of the `fetch` Backend for the `HttpClient`
#50247
This commit introduces a new HttpBackend implentation which makes requests using the fetch API
This feature is a developer preview and is opt-in.
It is enabled by setting the providers with provideHttpClient(withFetch()).
Currently the report progress is not implemented and using reportProgress: true will throw an error.
NB: The fetch API is experimental on Node but available without flags from Node 18 onwards.
NB2: The tests provided in the PR won't run, as fetch is not available on the node version provided by the bazel workspace (16.14)
Edit: pinning a answer I gave bellow on the purpose of this new backend:
Xhr is not supported natively on NodeJS an requires a polyfill. Currently Angular uses xhr2 for this. However, the polyfill is side-effectful and doesn't work in non-Node.js environments (such as Edge Workers). There are also others issues like https://github.com/angular/angular/issues/46930 (its doesn't support Gzip).
PR Type
What kind of change does this PR introduce?
- [x] Feature
Does this PR introduce a breaking change?
- [x] No
transform in @Input
The second feature introduced in Angular 16.1 is the addition of a transform function for the @Input decorator. This function enables mapping from one data type to another, making it particularly useful for "Router Parameters as Component Inputs", introduced in Angular 16.
For example, when receiving an ID parameter as a string, developers can use the transform function to map it to a number before assigning it to a property.
blog.ninja-squad.com
New RFCs
We have also received two new RFCs.
Built-In Control Flow
The first RFC proposes an alternative to the existing control-flow directives such as *ngIf or *ngFor. Rather than introducing new directives, it is a new syntax built directly into the template.
This eliminates the need for separate directive imports. This change is necessary to align with Signals.
The new template syntax is inspired by the Svelte framework.
Deferred Loading
The second RFC focuses on deferred loading of components and introduces a new template syntax for specifying conditions when a component should be loaded, such as visibility in the viewport.
It also allows developers to define the rendering behaviour for loading or error states. This feature aligns with similar functionality found in the React framework.
Top comments (6)
Short and great! I honestly really like the
transformfunctions in Inputs. It will save lots of OnChange implementations.It will basically render OnChange obsolete.
No, just think of use cases with a formGroup. When you have an input for the form's value, you need to run a side-effect by calling
formGroup.setValue(value).For these use cases, and there are plenty of, you still will use the
OnChange.And even if it is a transform function: As soon as it is not a one-liner and requires access to the dependency injection, you will go with
OnChangeagain.The OnChange is going to vanish eventually. But because of the Signal component which is expected in Angular 17.
Yes that was what I was referring to - signal based components. Cannot wait
Definitely. These are those kind of tiny details that have a deep impact.
Amazing, just loving the new direction of Angular. Signals and functional are just awesome!