{"id":6617,"date":"2022-11-02T12:09:31","date_gmt":"2022-11-02T11:09:31","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=6617"},"modified":"2022-11-02T12:09:31","modified_gmt":"2022-11-02T11:09:31","slug":"the-refurbished-httpclient-in-angular-15-standalone-apis-and-functional-interceptors","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/the-refurbished-httpclient-in-angular-15-standalone-apis-and-functional-interceptors\/","title":{"rendered":"The Refurbished HttpClient in Angular 15 – Standalone APIs and Functional Interceptors"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 6 of 8 in the series “Angular's Future with Standalone Components”<\/em>\t\t<\/p>\n\t\t\t<\/label>\n\n\t\t\t

\n\t\t\t
    \n\t\t\t\t\t\t\t\t\t
  1. Angular’s Future Without NgModules – Part 1: Lightweight Solutions Using Standalone Components<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  2. Angular’s Future Without NgModules – Part 2: What Does That Mean for Our Architecture?<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  3. 4 Ways to Prepare for Angular’s Upcoming Standalone Components<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  4. Routing and Lazy Loading with Angular’s Standalone Components<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  5. Angular Elements: Web Components with Standalone Components<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  6. The Refurbished HttpClient in Angular 15 – Standalone APIs and Functional Interceptors<\/span><\/li>\n\t\t\t\t\t\t\t\t\t
  7. Testing Angular Standalone Components<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  8. Automatic Migration to Standalone Components in 3 Steps<\/a><\/li>\n\t\t\t\t\t\t\t<\/ol>\n\t\t<\/div>\n\t<\/div>\n

    Without any doubt, the HttpClient<\/code> is one of the best-known services included in Angular. For version 15, the Angular team has now adapted it for the new standalone components. On this occasion, the interceptor concept was also revised.<\/p>\n

    In this article, I will describe these innovations. <\/p>\n

    \ud83d\udcc2 Source Code<\/a><\/p>\n

    Standalone APIs for HttpClient<\/h2>\n

    Beginning with version 15, there HttpClient<\/code> can be setup without any reference to the HttpClientModule<\/code>. Instead, we can use provideHttpClient<\/code> when bootstrapping our application:<\/p>\n

    import { provideHttpClient, withInterceptors } from "@angular\/common\/http";\n\n[...]\n\nbootstrapApplication(AppComponent, {\n    providers: [\n        provideHttpClient(\n            withInterceptors([authInterceptor]),\n        ),\n    ]\n});<\/code><\/pre>\n
    This new function also enables optional features of the HttpClient<\/code>. Each feature has its own function. For example, the withInterceptors<\/code> function enables support for Http Interceptors.<\/p>\n
    The combination of a provideXYZ<\/code> function and several optional withXYZ<\/code> functions is not chosen arbitrarily here but corresponds to a pattern that the Angular team generally provides for standalone APIs. Application developers must therefore be on the lookout for functions that start with provide<\/code> or with<\/code> when setting up a new library.<\/p>\n
    Also, this pattern leads to a very pleasant side effect: libraries become more tree-shakable. This is because a static source code analysis makes it very easy to find out whether the application ever calls a function. In the case of methods, this is not so easy due to the possibility of polymorphic use of the underlying objects.<\/p>\n
    Functional Interceptors<\/h2>\n
    When introducing standalone APIs, the Angular team also took the opportunity and revised the HttpClient<\/code> a bit. One result of this are the new functional interceptors. They allow interceptors to be expressed as simple functions. A separate service that implements a predefined interface is no longer necessary:<\/p>\n
    import { HttpInterceptorFn } from "@angular\/common\/http";\nimport { tap } from "rxjs";\n\nexport const authInterceptor: HttpInterceptorFn = (req, next) => {\n\n    console.log('request', req.method, req.url);\n    console.log('authInterceptor')\n\n    if (req.url.startsWith('https:\/\/demo.angulararchitects.io\/api\/')) {\n\n        \/\/ Setting a dummy token for demonstration\n\n        constheaders = req.headers.set('Authorization', 'Bearer Auth-1234567');\n\n        req = req.clone({\n            headers\n        });\n\n    }\n\n    return next(req).pipes(\n        tap(resp => console.log('response', resp))\n    );\n\n}<\/code><\/pre>\n
    The interceptor shown adds an exemplary security token to HTTP calls that are directed to specific URLs. Except that the interceptor is now a function of type HttpInterceptorFn<\/code>, the basic functionality of this concept has not changed. As shown above, functional interceptors can be set up using withInterceptors<\/code> when calling provideHttpClient<\/code> .<\/p>\n
    Interceptors and Lazy Loading<\/h2>\n
    Interceptors in lazy modules have always led to confusion: As soon as a lazy module introduces its own interceptors, those of outer scopes \u2013 e.g. the root scope \u2013 are no longer triggered.<\/p>\n
    Even if modules with standalone components and APIs are a thing of the past, the basic problem remains, especially since (lazy) route configurations can now set up their own services:<\/p>\n
    export const FLIGHT_BOOKING_ROUTES: Routes = [{\n    paths: '',\n    component: FlightBookingComponent,\n    providers: [\n        MyService,\n        provideState(bookingFeature),\n        provideEffects([BookingEffects])\n        provideHttpClient(\n            withInterceptors([bookingInterceptor]),\n            withRequestsMadeViaParent(),\n        ),\n    ],\n}];<\/code><\/pre>\n
    These services correspond to those the application previously registered in lazy modules. Technically, Angular introduces its own injector whenever such a providers<\/code> array is available. This so-called environment injector defines a scope for the current route and its child routes.<\/p>\n
    The new provideHttpClient<\/code> function can also be used in this providers<\/code> array to register interceptors for the respective lazy part of the application. By default, the previously discussed rule applies: If there are interceptors in the current environment injector, Angular ignores the interceptors in outer scopes.<\/p>\n
    Exactly this behavior can be changed with withRequestsMadeViaParent<\/code>: This method causes Angular to also trigger interceptors in outer scopes.<\/p>\n
    Pitfall with withRequestsMadeViaParent<\/h2>\n
    The discussed withRequestsMadeViaParent<\/code> function comes with a non-obvious pitfall: a root-scope service is unaware of inner scope and the interceptors registered there. It always accesses the HttpClient<\/code> in the root scope and therefore only the interceptors set up there are executed:<\/p>\n
    \"Interceptors<\/p>\n
    To solve this problem, the application could also register the outer service in the providers<\/code> array of the route configuration and thus in the inner scope.<\/p>\n
    In general, however, it seems to be very difficult to keep track of such constellations. Therefore, it might make sense to do without interceptors in inner scopes altogether. As an alternative, a very generic interceptor in the root scope could be used. Such an interceptor may even load additional logic with a dynamic import<\/code> from lazy applications parts.<\/p>\n
    Legacy Interceptors and Other Features<\/h2>\n
    While the new functional interceptors are very charming, applications can still take advantage of the original class-based interceptors. This option can be enabled using the withLegacyInterceptors feature<\/code>. Then, the class-based interceptors are to be registered as usual via a multi-provider:<\/p>\n
    bootstrapApplication(AppComponent, {\n    providers: [\n        provideHttpClient(\n            withInterceptors([authInterceptor]),\n            withLegacyInterceptors(),\n        ),\n        {\n            provide: HTTP_INTERCEPTORS,\n            useClass: LegacyInterceptor,\n            multiple: true,\n        },\n    ]\n});<\/code><\/pre>\n
    Further Features<\/h2>\n
    The HttpClient<\/code> has some additional features that can also be activated using with-<\/code>functions: withJsonpSupport<\/code>, for example, activates support for JSONP, and withXsrfConfiguration<\/code> configures details on the use of XSRF tokens. If the application does not call withXsrfConfiguration<\/code>, default settings are used. However, to completely disable the use of XSRF tokens, call withNoXsrfProtection<\/code>.<\/p>\n
    Summary<\/h2>\n
    The revised HttpClient<\/code> now wonderfully harmonizes with standalone components and associated concepts such as environment injectors. The Angular team also took the opportunity to revise the interceptors: They can now be implemented in the form of simple functions. In addition, it is now also possible to consider interceptors in outer scopes.<\/p>\n
    More on Standalone Components?<\/h2>\n
    Learn all about Standalone Components in our free eBook:<\/p>\n