{"id":5643,"date":"2022-05-01T17:00:34","date_gmt":"2022-05-01T15:00:34","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=5643"},"modified":"2022-05-01T17:00:34","modified_gmt":"2022-05-01T15:00:34","slug":"angulars-future-without-ngmodules-lightweight-solutions-on-top-of-standalone-components","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/angulars-future-without-ngmodules-lightweight-solutions-on-top-of-standalone-components\/","title":{"rendered":"Angular’s Future Without NgModules – Part 1: Lightweight Solutions Using Standalone Components"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 1 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<\/span><\/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<\/a><\/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

    Update on 2022-05-01<\/strong>: Texts and examples fully updated to use initial Standalone Components support in Angular 14.0.0-next.15<\/em> (instead of just using a shim for simulating them). <\/p>\n

    Update on 2022-10-09<\/strong>: Updated for Angular 14.2.0<\/em>.<\/p>\n

    <\/p>\n

    Standalone Components is one of the most exciting new Angular features since quite a time. They allow for working without NgModules and hence are the key for more lightweight and straightforward Angular solutions. A first implementation already landed in Angular 14 BETA and the Angular Team tries hard to make them available until version 14 is released in the first half of 2022. <\/p>\n

    In this article series, I'm going to demonstrate how to leverage this innovation. For this, I'm using an example application completely written with Standalone Components.<\/p>\n

    \nThe \ud83d\udcc2 source code<\/strong> for this can be found in the form of a traditional Angular CLI workspace<\/a> and as an Nx workspace<\/a> that uses libraries as a replacement for NgModules.\n<\/p><\/blockquote>\n

    Why Did we Even Get NgModules in the First Place?<\/h2>\n

    The main reason for initially introducing NgModules was pragmatic: We needed a way to group building blocks that are used together. Not only to increase the convenience for developers, but also for the Angular Compiler whose development lagged a little behind. In the latter case, we are talking about the compilation context. From this context, the compiler learns where the program code is allowed to call which components:<\/p>\n

    \"NgModules<\/p>\n

    However, the community was never really happy with this decision. Having another modular system besides that of EcmaScript didn't feel right. In addition, it raised the entry barrier for new Angular developers. That is why the Angular team designed the new Ivy compiler so that the compiled application works without modules at runtime. Each component compiled with Ivy has its own compilation context. Even if that sounds grandiose, this context is just represented by two arrays that refer to adjacent components, directives, and pipes.<\/p>\n

    Since the old compiler and the associated execution environment have now been permanently removed from Angular as of Angular 13, it was time to anchor this option in Angular's public API. For some time there has been a design document and an associated RFC [RFC]. Both describe a world where Angular modules are optional. The word optional is important here: Existing code that relies on modules is still supported.<\/p>\n

    Getting Started With Standalone Components<\/h2>\n

    In general, implementing a Standalone Component is easy. Just set the standalone<\/code> flag in the Component<\/code> decorator to true<\/code> and import everything you want to use:<\/p>\n

    @Component({\n  standalone: true,\n  selector: 'app-root',\n  imports: [\n    RouterOutlet,\n    NavbarComponent,\n    SidebarComponent,\n  ],\n  templateUrl: '.\/app.component.html',\n  styleUrls: ['.\/app.component.css']\n})\nexport class AppComponent {\n    [...]\n}<\/code><\/pre>\n
    The imports<\/code> define the compilation context: all the other building blocks the Standalone Components is allowed to use. For instance, you use it to import further Standalone Component, but also existing NgModules.<\/p>\n
    The exhaustive listing of all these building blocks makes the component self-sufficient and thus increases its reusability in principle. It also forces us to think about the component's dependencies. Unfortunately, this task turns out to be extremely monotonous and time consuming.<\/p>\n
    Therefore, there are considerations to implement a kind of auto-import in the Angular Language Service used by the IDEs. Analogous to the auto-import for TypeScript modules, the IDE of choice could also suggest placing the corresponding entry in the imports<\/code> array the first time a component, pipe or directive is used in the template.<\/p>\n
    The Mental Model<\/h2>\n
    The underlying mental model helps to better understand Standalone Components. In general, you can imagine a Standalone Component as a component with its very own NgModule:<\/p>\n
    \"Mental<\/p>\n
    This is similar to Lars Nielsen<\/a>'s SCAM pattern. However, while SCAM uses an explicit module, here we only talk about a thought one. <\/p>\n
    While this mental model is useful for understanding Angular's behavior, it's also important to see that Angular doesn't implement Standalone Components that way underneath the covers.<\/p>\n
    Pipes, Directives, and Services<\/h2>\n
    Analogous to standalone components, there are also standalone pipes and standalone directives. For this purpose, the pipe<\/code> and directive<\/code> decorators also get a standalone<\/code> property. This is what a standalone pipe will look alike:<\/p>\n
    @Pipe ({\n  standalone: true,\n  name: 'city',\n  pure: true\n})\nexport class CityPipe implements PipeTransform {\n\n  transform (value: string, format: string): string {[\u2026]}\n\n}<\/code><\/pre>\n
    And here is an example for a standalone directive:<\/p>\n
    @Directive ({\n    standalone: true,\n    selector: 'input [appCity]',\n    providers: [\u2026]\n})\nexport class CityValidator implements Validator {\n\n    [...]\n\n}<\/code><\/pre>\n
    Thanks to tree-shakable providers, on the other hand, services have worked without modules for quite a time. For this purpose the property providedIn<\/code> has to be used:<\/p>\n
    @Injectable ({\n  providedIn: 'root'\n})\nexport class FlightService {[\u2026]}<\/code><\/pre>\n
    In a later part of this article series, we will look more closely to dependency injection in a world of Standalone Components. However, to anticipate one key point already now: Using modern tree-shakable providers instead of old-style providers in NgModules helps a lot when migrating to Standalone Components.<\/p>\n
    The Angular team recommends, to use providedIn: 'root'<\/code> whenever possible. It might come as a surprise, but providedIn: 'root'<\/code> also works with lazy loading: If you only use a service in lazy parts of your application, it is loaded alongside them.<\/p>\n
    Bootstrapping Standalone Components<\/h2>\n
    Until now, modules were also required for bootstrapping, especially since Angular expected a module with a bootstrap component. Thus, this so called AppModule<\/code> or "root module" defined the main component alongside its compilation context. <\/p>\n
    With Standalone Components, it will be possible to bootstrap a single component. For this, Angular provides a method bootstrapApplication<\/code> which can be used in main.ts<\/code>:<\/p>\n
    \/\/ main.ts\n\nimport { bootstrapApplication } from '@angular\/platform-browser';\nimport { provideAnimations } from '@angular\/platform-browser\/animations';\nimport { AppComponent } from '.\/app\/app.component';\nimport { APP_ROUTES } from '.\/app\/app.routes';\nimport { provideRouter } from '@angular\/router';\nimport { importProvidersFrom } from '@angular\/core';\n\n[...]\n\nbootstrapApplication(AppComponent, {\n  providers: [\n    importProvidersFrom(HttpClientModule),\n    provideRouter(APP_ROUTES),\n    provideAnimations(),\n    importProvidersFrom(TicketsModule),\n    importProvidersFrom(LayoutModule),\n  ]\n});<\/code><\/pre>\n
    The first argument passed to bootstrapApplication<\/code> is the main component. Here, it's our AppComponent<\/code>. Via the second argument, we pass application-wide service providers. These are the providers, you would register with the AppModule<\/code> when going with NgModules.<\/p>\n
    The provided helper function importProvidersFrom<\/code> allows bridging the gap to existing NgModules. Please also note, that importProvidersFrom<\/code> works with both NgModules but also ModuleWithProviders<\/code> as returned by methods like forRoot<\/code> and forChild<\/code>. <\/p>\n
    While this allows to immediately leverage existing NgModule-based APIs, we will see more and more functions that replace the usage of importProvidersFrom<\/code> in the future. For instance, to register the router with a given configuration, the function provideRouter<\/code> is used. Similarly, provideAnimations setup up the Animation module.<\/p>\n
    Compatibility With Existing Code<\/h2>\n
    As discussed above, according to the mental model, a Standalone Component is just a component with its very own NgModule. This is also the key for the compatibility with existing code still using NgModules. <\/p>\n
    On the one side, we can import whole NgModules into a Standalone Component:<\/p>\n
    import { Component, OnInit } from '@angular\/core';\nimport { TicketsModule } from '..\/tickets\/tickets.module';\n\n@Component({\n    selector: 'app-next-flight',\n    standalone: true,\n    imports: [\n        \/\/ Existing NgModule imported \n        \/\/ in this standalone component\n        TicketsModule\n    ],\n    [...]\n})\nexport class NextFlightComponent implements OnInit {\n    [...]\n}<\/code><\/pre>\n
    But on the other side, we can also import a Standalone Component (Directive, Pipe) into an existing NgModule:<\/p>\n
    @NgModule({\n  imports: [\n    CommonModule,\n\n    \/\/ Imported Standalone Component:\n    FlightCardComponent,\n    [...]\n  ],\n  declarations: [\n    MyTicketsComponent\n  ],\n  [...]\n})\nexport class TicketsModule { }<\/code><\/pre>\n
    Interestingly, standalone components are imported<\/strong> like modules and not declared like classic components. This may be confusing at first glance, but it totally fits the mental model that views a standalone component a component with its very own NgModule.<\/p>\n
    Also, declaring a traditional component defines a strong whole-part relationship: A traditional component can only be declared by one module and then, it belongs to this module. However, a standalone component doesn't belong to any NgModule but it can be reused in several places. Hence, using imports<\/code> here really makes sense.<\/p>\n
    Side Note: The CommonModule<\/h2>\n
    Doubtless, one of the most known NgModules in Angular was the CommonModule<\/code>. It contains built-in directives like ngIf<\/code> or <\/em>ngFor<\/code> and built-in pipes like async<\/code> or json<\/code>. While you can still import the whole CommonModule<\/code>, meanwhile it's also possible to just import the needed directives and pipes:<\/p>\n
    import { \n    AsyncPipe, \n    JsonPipe, \n    NgForOf, \n    NgIf \n} from "@angular\/common";\n\n[...]\n\n@Component({\n  standalone: true,\n  imports: [\n    \/\/ CommonModule, \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 implements OnInit {\n    [...]\n}<\/code><\/pre>\n
    This is possible, because the Angular team made Standalone Directives and Standalone Pipes out of the building blocks provided by the CommonModule<\/code>. Importing these building blocks in a fine grained way will be especially interesting once IDEs provide auto-imports for standalone components. In this case, the first usage of an building block like *ngIf<\/code> will make the IDE to add it to the imports<\/code> array. <\/p>\n
    \nAs we will see in a further part of this series, meanwhile also the RouterModule<\/code> comes with Standalone building-blocks. Hence, we can directly import RouterOutlet instead of going with the whole RouterModule<\/code>. When writing this, this was not yet possible for other modules like the FormsModule<\/code> or the HttpClientModule<\/code>.\n<\/p><\/blockquote>\n
    Interim Conclusion: Standalone Components -- and now?<\/h2>\n
    So far we've seen how to use Standalone Components to make our Angular applications more lightweight. We've also seen that the underlying mental model guarantees compatibility with existing code. <\/p>\n
    However, now the question arises how this all will influence our application structure and architecture. The next part of this short series will shed some light on this.<\/p>\n
    » Next Part:<\/strong> Angular's Future Without NgModules - Part 2: What Does That Mean for Our Architecture?<\/a><\/p>\n
    More on Architecture?<\/h2>\n
    When architecting enterprise-scale Angular applications, several additional questions come in mind:<\/p>\n