{"id":5649,"date":"2022-05-01T17:09:41","date_gmt":"2022-05-01T15:09:41","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=5649"},"modified":"2022-05-01T17:09:41","modified_gmt":"2022-05-01T15:09:41","slug":"angulars-future-without-ngmodules-part-2-what-does-that-mean-for-our-architecture","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/angulars-future-without-ngmodules-part-2-what-does-that-mean-for-our-architecture\/","title":{"rendered":"Angular’s Future Without NgModules – Part 2: What Does That Mean for Our Architecture?"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 2 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?<\/span><\/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>: Update for Angular 14.2.0<\/em><\/p>\n

    <\/p>\n

    In the first part<\/a> of this short series, I've shown how Standalone Components will make our Angular applications more lightweight in the future. In this part, I'm discussing options for improving your architecture with them.<\/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

    Grouping Building Blocks<\/h2>\n

    Unfortunately, the examples shown in the first part of this series cannot keep up with one aspect of NgModules. Namely the possibility of grouping building blocks that are usually used together. <\/p>\n

    Obviously, the easiest approach for grouping stuff that goes together is using folders. However, you might go one step further by leveraging barrels: A barrel is an EcmaScript file that exports related elements.<\/p>\n

    These files are often called public-api.ts<\/code> or index.ts<\/code>. The example project used contains such an index.ts<\/code> to group two navigation components from the shell folder:<\/p>\n

    \"Grouping<\/p>\n

    The barrel itself re-exports the two components:<\/p>\n

    export { NavbarComponent } from '.\/navbar\/navbar.component';\nexport { SidebarComponent } from '.\/sidebar\/sidebar.component';<\/code><\/pre>\n
    The best of this is, you get real modularization: Everything the barrel experts can be used by other parts of your application. Everything else is your secret. You can modify these secrets as you want, as long as the public API defined by your barrel stays backwards compatible. <\/p>\n
    In order to use the barrel, just point to it with an import<\/code>:<\/p>\n
    import { \n    NavbarComponent, \n    SidebarComponent \n} from '.\/shell\/index';\n\n@Component({\n    standalone: true,\n    selector: 'app-root',\n    imports: [\n        RouterOutlet,\n\n        NavbarComponent,\n        SidebarComponent,\n    ],\n    templateUrl: '.\/app.component.html',\n    styleUrls: ['.\/app.component.css']\n})\nexport class AppComponent {\n    [...]\n}<\/code><\/pre>\n
    If you call your barrel index.ts<\/code>, you can even omit the file name, as index<\/code> is the default name when configuring the TypeScript compiler to use Node.js-based conventions. Something that is the case in the world of Angular and the CLI:<\/p>\n
    import { \n    NavbarComponent, \n    SidebarComponent \n} from '.\/shell';\n\n@Component({\n    standalone: true,\n    selector: 'app-root',\n    imports: [\n        RouterOutlet,\n\n        NavbarComponent,\n        SidebarComponent,\n    ],\n    templateUrl: '.\/app.component.html',\n    styleUrls: ['.\/app.component.css']\n})\nexport class AppComponent {\n    [...]\n}<\/code><\/pre>\n
    Importing Whole Barrels<\/h2>\n
    In the last section, the NavbarComponent<\/code> and the SidebarComponent<\/code> were part of the shell's public API. Nevertheless. Angular doesn't provide a way to import everything a barrel provides at once. <\/p>\n
    In most of the cases, this is the totally fine. Auto-imports will add the needed entries anyway, hence this style of programming is easy. Also, being explicit about what you need helps enables tree-shaking. <\/p>\n
    However, in some edge-cases where you know that some building blocks always<\/strong> go together, e. g. because there is a strong mutual dependency, putting them into an  array can help to make our lives easier. For instance, think about all the directives provided by the FormsModule. Normally, we don't even know their exact names nor which of them play together. <\/p>\n
    The following example demonstrates this idea:<\/p>\n
    import { NavbarComponent } from '.\/navbar\/navbar.component';\nimport { SidebarComponent } from '.\/sidebar\/sidebar.component';\n\nexport { NavbarComponent } from '.\/navbar\/navbar.component';\nexport { SidebarComponent } from '.\/sidebar\/sidebar.component';\n\nexport const SHELL = [\n    NavbarComponent,\n    SidebarComponent\n];<\/code><\/pre>\n
    Interestingly, such arrays remind us to the exports<\/code> section of NgModules. Please note that your array needs to be a constant. This is needed because the Angular Compiler uses it already at compile time.<\/p>\n
    Such arrays can be directly put into the imports<\/code> array. No need for spreading them: <\/p>\n
    import { SHELL } from '.\/shell';\n\n[...]\n\n@Component({\n    standalone: true,\n    selector: 'app-root',\n    imports: [\n        RouterOutlet,\n\n        \/\/ NavbarComponent,\n        \/\/ SidebarComponent,\n        SHELL\n    ],\n    templateUrl: '.\/app.component.html',\n    styleUrls: ['.\/app.component.css']\n})\nexport class AppComponent {\n    [...]\n}<\/code><\/pre>\n
    One more time I want to stress out that this array-based style should only be used with caution. While it allows to group things that always go together it also makes your code less tree-shakable.<\/p>\n
    Barrels with Pretty Names: Path Mappings<\/h2>\n
    Just using import<\/code> statements that directly point to other parts of your application often leads to long relative and confusing paths: <\/p>\n
    import { SHELL } from '..\/..\/..\/..\/shell';\n\n@Component ({\n    standalone: true,\n    selector: 'app-my-cmp',\n    imports: [\n        SHELL,\n        [...]\n    ]\n})\nexport class MyComponent {\n}<\/code><\/pre>\n
    To bypass this, you can define path mappings for your  barrels you import from in your TypeScript configuration (tsconfig.json<\/code> in the project's root):<\/p>\n
    "paths": {\n "@demo\/shell": ["src\/app\/shell\/index.ts"],\n  [...]\n}<\/code><\/pre>\n
    This allows direct access to the barrel using a well-defined name without having to worry about - sometimes excessive - relative paths:<\/p>\n
    \/\/ Import via mapped path:\nimport { SHELL } from '@demo\/shell';\n\n@Component ({\n    standalone: true,\n    selector: 'app-root',\n    imports: [\n        SHELL,\n        [...]\n    ]\n})\nexport class MyComponent {\n}<\/code><\/pre>\n
    The Next Logical Step: Workspace Libraries and Nx<\/h2>\n
    These path mappings can of course be created manually. However, it is a little easier with the CLI extension Nx<\/a> which automatically generates such path mappings for each library created within a workspace. Libraries seem to be the better solution anyway, especially since they subdivide it more and Nx prevents bypassing the barrel of a library.<\/p>\n
    This means that every library consists of a public -- actually published -- and a private part. The library\u2019s public and private APIs are also mentioned here. Everything the library exports through its barrel is public. The rest is private and therefore a "secret" of the library that other parts of the application cannot access.<\/p>\n
    It is precisely these types of "secrets" that are a simple but effective key to stable architectures, especially since everything that is not published can easily be changed afterwards. The public API, on the other hand, should only be changed with care, especially since a breaking change can cause problems in other areas of the project.<\/p>\n
    An Nx project (workspace) that represents the individual sub-areas of the Angular solution as libraries could use the following structure:<\/p>\n
    \"Structure<\/p>\n
    Each library receives a barrel that reflects the public API. The prefixes in the library names reflect a categorization recommended by the Nx team. For example, feature libraries contain smart components that know the use cases, while UI libraries contain reusable dumb components. The domain library comes with the client-side view of our domain model and the services operating on it, and utility libraries contain general auxiliary functions.<\/p>\n
    On the basis of such categories, Nx allows the definition of linting rules that prevent undesired access between libraries. For example, you could specify that a domain library should only have access to utility libraries and not to UI libraries:<\/p>\n
    \"Nx<\/p>\n
    In addition, Nx allows the dependencies between libraries to be visualized:<\/p>\n
    \"Nx<\/p>\n
    If you want to see all of this in action, feel free to have a look at the Nx version of the example used here. Your find the \ud83d\udcc2 Source Code at GitHub<\/a>.<\/p>\n
    Also, our article series on Nx and DDD<\/a> (esp. Strategic Design) discusses the underlying ideas in detail.<\/p>\n
    Conclusion<\/h2>\n
    Standalone Components make the future of Angular applications more lightweight. We don't need NgModules anymore. Instead, we just use EcmaScript modules. This makes Angular solutions more straightforward and lowers the entry barrier into the world of the framework. Thanks to the mental model, which regards standalone components as a combination of a component and a NgModule, this new form of development remains compatible with existing code.<\/p>\n
    For the grouping of related building blocks, simple barrels are ideal for small solutions. For larger projects, the transition to monorepos as offered by the CLI extension Nx seems to be the next logical step. Libraries subdivide the overall solution here and offer public APIs based on barrels. In addition, dependencies between libraries can be visualized and avoided using linting.<\/p>\n
    What's next? More on Architecture!<\/h2>\n
    So far, we've seen that Nx can help to structure Angular-based applications and that it's concepts fit perfectly to the new world of Standalone Components. However, when dealing with Nx, several additional questions come in mind:<\/p>\n