{"id":6797,"date":"2023-01-12T09:52:24","date_gmt":"2023-01-12T08:52:24","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=6797"},"modified":"2023-09-04T12:57:26","modified_gmt":"2023-09-04T10:57:26","slug":"modern-and-lightweight-angular-architectures-with-angulars-latest-innovations","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/modern-and-lightweight-angular-architectures-with-angulars-latest-innovations\/","title":{"rendered":"Modern and Lightweight Angular Architectures With Angular’s Latest Innovations"},"content":{"rendered":"

In the last time, Angular has received several new features that make it possible to use the framework in a fresh and lightweight way. This article series shows how these innovations help make our solutions more maintainable.<\/p>\n

The examples used can be found under Example<\/a>.<\/p>\n

Standalone Components<\/h2>\n

I start with what is probably the biggest innovation of the last releases: the long-awaited Standalone Components. Since they do not need NgModules<\/code>, there are no unneeded indirection anymore. This makes the application a more lightweight. To tell Angular that a Component is standalone, set the standalone<\/code> flag to true<\/code>:<\/p>\n

@Component({\n  standalone: true,\n  imports: [\n    NgIf,\n    NgForOf,\n    AsyncPipe,\n    JsonPipe,\n\n    FormsModule, \n    FlightCardComponent,\n    CityValidator,\n  ],\n  selector: 'flight-search',\n  templateUrl: '.\/flight-search.component.html'\n})\nexport class FlightSearchComponent {\n    private store = inject(Store);\n    readonly flights$ = this.store.select(selectFilteredFlights);\n\n    [\u2026]\n}<\/code><\/pre>\n
In addition, it is now necessary to provide the compilation context via the new imports<\/code> array. This includes all other components, but also directives and pipes that are used in the template of the Standalone Component. Existing NgModules<\/code> can also be imported. This is necessary to continue supporting existing code. The Angular team thus avoids breaking changes.<\/p>\n
Also, even the building blocks supplied with Angular are not yet completely free of NgModules<\/code>. The example shown partially reflects this: While the components of the CommonModule<\/code>, including NgIf<\/code>, NgFor<\/code>, AsyncPipe,<\/code> and JsonPipe<\/code> are now standalone, this is not yet the case with the FormsModule<\/code>.<\/p>\n
The previous example also shows another innovation that makes Angular solutions lighter: Dependencies can now be injected directly into properties using inject<\/code>. The component does not have to introduce its own constructor for this.<\/p>\n
More details about Standalone Components<\/a> can be found here<\/a>.<\/p>\n
inject and the EcmaScript Standard<\/h2>\n
Using inject<\/code> also has another not-so-obvious benefit: the injected dependency can provide default values for other properties. In the example shown, the injected store<\/code> returns a default value for flights$<\/code>.<\/p>\n
In the past, this also worked with dependencies injected via the constructor. However, this procedure is not EcmaScript-compliant! EcmaScript first populates the properties with default values and only then executes the constructor. TypeScript now follows this specification. However, most Angular don\\'t recognize this behavior because the Angular CLI activates the original behavior with a flag in the TypeScript configuration. With inject<\/code>, on the other hand, we are per se standard-compliant and on the safe side even without this setting!<\/p>\n
Bootstrapping a Standalone Component<\/h2>\n
The bootstrapping of the application is also easier thanks to standalone components: You only have to transfer the AppComponent<\/code> to bootstrapApplication<\/code>. Global providers can be set up using the second argument:<\/p>\n
bootstrapApplication(AppComponent, {\n  providers: [\n    provideHttpClient(\n      withInterceptors([authInterceptor]),\n    ),\n    provideRouter(APP_ROUTES, \n      withPreloading(PreloadAllModules),\n    ),\n    provideLogger({ debug: true }, \n          CustomLogFormatter);\n  ]\n}<\/code><\/pre>\n
Both the HttpClient<\/code> and the router now come with helper functions for setting up the required global providers. The Angular team follows the provideXYZ<\/code> naming pattern, which it also recommends for third-party libraries. The example shown also applies this pattern to a custom logger library. The next section shows how to create such a function for setting up your own library.<\/p>\n
Own Provide Functions<\/h2>\n
Actually, provide<\/code> functions for setting up libraries are nothing special. They accept the configuration parameters and return an array with providers:<\/p>\n
export function provideLogger(config: LoggerConfig, \n        formatterClass: Type<LogFormatter>): EnvironmentProviders {\n  return makeEnvironmentProviders([\n    {\n      provide: LoggerConfig,\n      useValue: config,\n    },\n    {\n      provide: LogFormatter,\n      useClass: formatterClass,\n    },\n  ]);\n}<\/code><\/pre>\n
However, the Angular team does not use the Provider[]<\/code> type for the return value, but rather EnvironmentProviders<\/code>. Using the type system, this procedure ensures that the providers supplied can only be registered together with bootstrapApplication<\/code> and within router configurations. However, this excludes registration as a local provider within a component. This is important since most libraries are shared between multiple components. To create this type, Angular provides the makeEnvironmentProviders<\/code> function.<\/p>\n
More details on custom provide function<\/a> can be found in my article here<\/a>.<\/p>\n
Functional Interceptors<\/h2>\n
One of the most powerful features of the HttpClient<\/code> are interceptors. They provide central routines that can process all outgoing HTTP requests and incoming HTTP responses.<\/p>\n
Originally, these were services that were to be provided via a multi-provider. However, when revising the HttpClient<\/code>, which became necessary as part of the switch to standalone components, the Angular team created a lighter variant: functional interceptors.<\/p>\n
These are simple functions that take the current HTTP request and a reference called next<\/code>. This reference points either to another interceptor, if one exists, or to the logic that takes care of the desired HTTP request:<\/p>\n
export const authInterceptor: HttpInterceptorFn = (req, next) => {\n\n    if (req.url.startsWith('https:\/\/demo.angulararchitects.io\/api\/')) {\n        \/\/ Setting a dummy token for demonstration\n        const headers = req.headers.set('Authorization', 'Bearer Auth-1234567');\n        req = req.clone({headers});\n    }\n\n    return next(req).pipe(\n        tap(resp => console.log('response', resp))\n    );\n}<\/code><\/pre>\n
In order to make the application\\'s functional interceptor known, it must be passed to provideHttpClient<\/code> (see example above). The originally necessary packaging into a service and registration via a multi-provider is no longer necessary.<\/p>\n
More details about Functional Interceptors and the Standalone API for the HttpClient<\/a> can be found here<\/a>.<\/p>\n
More: Angular Architecture Workshop (online, interactive, advanced)<\/h3>\n
Become an expert for enterprise-scale and maintainable Angular applications with our Angular Architecture workshop!<\/a>\"\"<\/p>\n
All Details (English Workshop)<\/a> | All Details (German Workshop)<\/a><\/p>\n
Functional Guards and Resolvers<\/h2>\n
Similar to interceptors, guards and resolvers can now also be just functions. In cases where these constructs only delegate to services, they can even be reduced to a one-liner:<\/p>\n
export const APP_ROUTES: Routes = [\n    [\u2026]\n    {\n        path: 'flight-booking',\n        canActivate: [() => inject(AuthService).isAuthenticated()],\n        resolve: {\n          config: () => inject(ConfigService).loaded$,\n        },\n        loadChildren: () =>\n            import('.\/booking\/flight-booking.routes')\n               \/\/ .then(m => m.FLIGHT`BOOKING`ROUTES)\n    },\n    [\u2026]\n]<\/code><\/pre>\n
In the example shown, a canActivate<\/code> guard prevents unauthenticated users from activating a route. To do this, it delegates to the AuthService<\/code> , which can be obtained via inject<\/code> .<\/p>\n
The resolver is similar: it delays the activation of the route until a configuration has been loaded. It also obtains the ConfigService<\/code> required for this via inject<\/code>.<\/p>\n
This example also shows another new possibility that has also shortened lazy loading somewhat since Angular 15: The loadChildren<\/code> property now uses the default expert. A projection onto the desired export indicated in the source code comment is no longer necessary.<\/p>\n
More Details on Routing With Standalone Components<\/a> can be found here<\/a>.<\/p>\n
Host Directives<\/h2>\n
The host directives introduced with Angular 15 allow reusable features to be included in components and directives. These are directives that are imported directly into other components and directives. There is now a new property hostDirectives<\/code> in the directive and component decorator:<\/p>\n
@Component({\n  selector: 'tickets-flight-lookup',\n  standalone: true,\n  hostDirectives: [LifeCycle],\n  [\u2026]\n})\nexport class FlightLookupComponent implements OnInit {\n  facade = inject(FlightLookupFacade);\n  lifeCycle = inject(LifeCycle);\n\n  flights$ = this.facade.flights$;\n\n  ngOnInit(): void {\n\n    this.flights$.pipe(takeUntil(this.lifeCycle.destroy$))\n        .subscribe((v) => {\n          console.log('online', v);\n        });\n  }\n}<\/code><\/pre>\n
An interesting feature of host directives is that they share the lifecycle with the consuming component or directive, but also that they can be injected like traditional services. This allows, for example, the provision of observables that represent life cycle hooks. Such constructs make it easier, among other things, to close resources using takeUntil<\/code>, as shown in the previous example. The implementation of the host directive used for this can be found in the next one:<\/p>\n
@Directive({\n  standalone: true,\n})\nexport class LifeCycle implements [\u2026], OnDestroy {\n  [\u2026]\n\n  private destroySubject = new Subject<void>();\n  readonly destroy$ = this.destroySubject.asObservable();\n\n  [\u2026]\n\n  ngOnDestroy(): void {\n    this.destroySubject.next();\n  }\n}<\/code><\/pre>\n
Another Small Step: Self-Closing Tags<\/h2>\n
Another small new feature that helps to make our solutions more lightweight is self-closing tags. Beginning with Angular 15.1.0 we can now write<\/p>\n
<flight-card [item]="f" [(selected)]="basket[f.id]" \/><\/code><\/pre>\n
instead of<\/p>\n
<flight-card [item]="f" [(selected)]="basket[f.id]">\n<\/flight-card><\/code><\/pre>\n
Obviously, this is a tiny new feature. However, it\\'s another piece in the mosaic of more lightweight applications.<\/p>\n
What\\'s next? More on Architecture!<\/h2>\n
Please find more information on enterprise-scale Angular architectures in our free eBook (5th edition, 12 chapters):<\/p>\n