{"id":6199,"date":"2022-05-25T18:59:55","date_gmt":"2022-05-25T16:59:55","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=6199"},"modified":"2022-05-25T18:59:55","modified_gmt":"2022-05-25T16:59:55","slug":"routing-and-lazy-loading-with-standalone-components","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/routing-and-lazy-loading-with-standalone-components\/","title":{"rendered":"Routing and Lazy Loading with Angular’s Standalone Components"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 4 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<\/span><\/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-10-10<\/strong>: Updated for Angular 14.2.0<\/em>.<\/p>\n

    Since its first days, the Angular Router has always been
    \nquite coupled to NgModules. Hence, one question that comes up when moving to Standalone Components is: How will routing and lazy loading work without NgModules? This article provides answers and also shows, why the router will become more important for Dependency Injection.<\/p>\n

    \nBig thanks to Pawel Kozlowski<\/a> from the Angular team for proofreading this article!<\/p>\n

    The \ud83d\udcc2 source code<\/strong> for the examples used here 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

    Providing the Routing Configuration<\/h2>\n

    When bootstrapping a standalone component, we can provide services for the root scope. These are services you used to provide in your AppModule<\/code>. Meanwhile, the Router provides a function provideRouter<\/code> that returns all providers we need to register here:<\/p>\n

    \/\/ main.ts\n\nimport { importProvidersFrom } from '@angular\/core';\nimport { bootstrapApplication } from '@angular\/platform-browser';\nimport { \n    PreloadAllModules, \n    provideRouter, \n    withDebugTracing, \n    withPreloading, \n    withRouterConfig \n} \nfrom '@angular\/router';\n\nimport { APP_ROUTES } from '.\/app\/app.routes';\n[...]\n\nbootstrapApplication(AppComponent, {\n  providers: [\n    importProvidersFrom(HttpClientModule),\n    provideRouter(APP_ROUTES, \n      withPreloading(PreloadAllModules),\n      withDebugTracing(),\n    ),\n\n    [...]\n\n    importProvidersFrom(TicketsModule),\n    provideAnimations(),\n    importProvidersFrom(LayoutModule),\n  ]\n});<\/code><\/pre>\n
    The function provideRouter<\/code> not only takes the root routes but also the implementation of additional router features. These features are passed with functions having the naming pattern withXYZ<\/code>, e. g. withPreloading<\/code> or withDebugTracing<\/code>. As functions can easily be tree-shaken, this design decisions makes the whole router more tree-shakable. <\/p>\n
    \nWith the discussed functions, the Angular team also introduces a naming pattern, library authors should follow. Hence, when adding a new library, we just need to look out for an provideXYZ<\/code> and for some optional withXYZ<\/code> functions.\n<\/p><\/blockquote>\n
    As currently not every library comes with a provideXYZ<\/code> function yet, Angular comes with the bridging function importProvidersFrom<\/code>. It allows to get hold of all the providers defined in existing NgModules<\/code> and hence is the key for using them with Standalone Components. <\/p>\n
    I'm quite sure, the usage of importProvidersFrom<\/code> will peak off over time, as more and more libraries will provide functions for directly configuring their providers. For instance, NGRX recently introduced a provideStore<\/code> and a provideEffects<\/code> function.<\/p>\n
    Using Router Directives<\/h2>\n
    After setting up the routes, we also need to define a placeholder where the Router displays the activated component and links for switching between them. To get the directives needed for this, you might directly import the RouterModule into your Standalone Component. However, a better alternative is to just import the directives you need:<\/p>\n
    @Component({\n  standalone: true,\n  selector: 'app-root',\n  imports: [\n    \/\/ Just import the RouterModule:\n    \/\/ RouterModule,\n\n    \/\/ Better: Just import what you need:\n    RouterOutlet,\n    RouterLinkWithHref,\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
    Just importing the actually needed directives is possible, because the router exposed them as Standalone Directives. Please note that RouterLinkWithHref<\/code> is needed if you use routerLink<\/code> with an a<\/code>-tag; in all other cases you should import RouterLink<\/code> instead. While this might sound confusing, this is nothing we need to worry about in the mid-term when IDEs start providing auto-imports for Standalone Components.<\/p>\n
    Lazy Loading with Standalone Components<\/h2>\n
    In the past, a lazy route pointed to an NgModule<\/code> with child routes. As there are no NgModules<\/code> anymore, loadChildren<\/code> can now directly point to a lazy routing configuration:<\/p>\n
    \/\/ app.routes.ts\n\nimport { Routes } from '@angular\/router';\nimport { HomeComponent } from '.\/home\/home.component';\n\nexport const APP_ROUTES: Routes = [\n    {\n        path: '',\n        pathMatch: 'full',\n        redirectTo: 'home'\n    },\n    {\n        path: 'home',\n        component: HomeComponent\n    },\n\n    \/\/ Option 1: Lazy Loading another Routing Config\n    {\n        path: 'flight-booking',\n        loadChildren: () =>\n            import('.\/booking\/flight-booking.routes')\n                .then(m => m.FLIGHT_BOOKING_ROUTES)\n    },\n\n    \/\/ Option 2: Directly Lazy Loading a Standalone Component\n    {\n        path: 'next-flight',\n        loadComponent: () => \n            import('.\/next-flight\/next-flight.component')\n                .then(m => m.NextFlightComponent)\n    },\n    [...]\n];<\/code><\/pre>\n
    This removes the indirection via an NgModule<\/code> and makes our code more explicit. As an alternative, a lazy route can also directly point to a Standalone Component. For this, the above shown loadComponent<\/code> property is used.<\/p>\n
    I expect that most teams will favor the first option, because normally, an application needs to lazy loading several routes that go together.<\/p>\n
    Environment Injectors: Services for Specific Routes<\/h2>\n
    With NgModule<\/code>s, each lazy module introduced a new injector and hence a new injection scope. This scope was used for providing services only needed by the respective lazy chunk. <\/p>\n
    To cover such use cases, the Router now allows for introducing providers for each route. These services can be used by the route in question and their child routes:<\/p>\n
    \/\/ booking\/flight-booking.routes.ts\n\nexport const FLIGHT_BOOKING_ROUTES: Routes = [{\n    path: '',\n    component: FlightBookingComponent,\n    providers: [\n        provideBookingDomain(config)\n    ],\n    children: [\n        {\n            path: '',\n            pathMatch: 'full',\n            redirectTo: 'flight-search'\n        },\n        {\n            path: 'flight-search',\n            component: FlightSearchComponent\n        },\n        {\n            path: 'passenger-search',\n            component: PassengerSearchComponent\n        },\n        {\n            path: 'flight-edit\/:id',\n            component: FlightEditComponent\n        }\n    ]\n}];<\/code><\/pre>\n
    As shown here, we can provide services for several routes by grouping them as child routes. In these cases, a component-less parent route with an empty path (path: ''<\/code>) is used. This pattern is already used for years to assign Guards to a group of routes.<\/p>\n
    Technically, using adding a providers<\/code> array to a router configuration introduces a new injector at the level of the route. Such an injector is called Environment Injector and replaces the concept of the former (Ng)Module Injectors. The root injector and the platform injector are further Environment Injectors.<\/p>\n
    Interestingly, this also decouples lazy loading from introducing further injection scopes. Previously, each lazy<\/strong> NgModule<\/code> introduced a new injection scope, while non-lazy<\/strong> NgModule<\/code>s never did. Now, lazy loading itself doesn't influence the scopes. Instead, now, you define new scopes by adding a providers<\/code> array to your routes, regardless<\/strong> if the route is lazy or not. <\/p>\n
    The Angular team recommends to use this providers array with caution and to favor<\/strong> providedIn: 'root'<\/code> instead. As already mentioned in a previous article of this series, also providedIn: 'root'<\/code> allows for lazy loading. If you just use a services provided with providedIn: 'root'<\/code> in lazy parts of your application, they will only be loaded together with them.<\/p>\n
    However, there is one situation where providedIn: 'root'<\/code> does not work and hence the providers array shown is needed, namely if you need to pass a configuration to a library. I've already indicated this in the above example by passing a config object to my custom provideBookingDomain<\/code>. The next section provides a more elaborated example for this using NGRX.<\/p>\n
    Setting up NGRX and Feature Slices<\/h2>\n
    To illustrate how to use libraries adopted for Standalone Components with lazy loading, let's see how to setup NGRX. Let's start with providing the needed global services:<\/p>\n
    import { bootstrapApplication } from '@angular\/platform-browser';\n\nimport { provideStore } from '@ngrx\/store';\nimport { provideEffects } from '@ngrx\/effects';\nimport { provideStoreDevtools } from '@ngrx\/store-devtools';\n\nimport { reducer } from '.\/app\/+state';\n\n[...]\n\nbootstrapApplication(AppComponent, {\n  providers: [\n    importProvidersFrom(HttpClientModule),\n    provideRouter(APP_ROUTES, \n      withPreloading(PreloadAllModules),\n      withDebugTracing(),\n    ),\n\n    \/\/ Setup NGRX:\n    provideStore(reducer),\n    provideEffects([]),\n    provideStoreDevtools(),\n\n    importProvidersFrom(TicketsModule),\n    provideAnimations(),\n    importProvidersFrom(LayoutModule),\n  ]\n});<\/code><\/pre>\n
    For this, we go with the functions provideStore<\/code>, provideEffects<\/code>, and provideStoreDevtools<\/code> NGRX comes with since version 14.3<\/code>.<\/p>\n
    To allow lazy parts of the application to have their own feature slices, we call provideState<\/code> and provideEffects<\/code> in the respective routing configuration:<\/p>\n
    import { provideEffects } from "@ngrx\/effects";\nimport { provideState } from "@ngrx\/store";\n\nexport const FLIGHT_BOOKING_ROUTES: Routes = [{\n    path: '',\n    component: FlightBookingComponent,\n    providers: [\n        provideState(bookingFeature),\n        provideEffects([BookingEffects])\n    ],\n    children: [\n        {\n            path: 'flight-search',\n            component: FlightSearchComponent\n        },\n        {\n            path: 'passenger-search',\n            component: PassengerSearchComponent\n        },\n        {\n            path: 'flight-edit\/:id',\n            component: FlightEditComponent\n        }\n    ]\n}];<\/code><\/pre>\n
    While provideStore<\/code> sets up the store at root level, provideState<\/code> sets up additional feature slices. For this, you can provide a feature or just a branch name with a reducer. Interestingly, the function provideEffects<\/code> is used at the root level but also at the level of lazy parts. Hence, it provides the initial effects but also effects needed for a given feature slice.<\/p>\n
    Setting up Your Environment: ENVIRONMENT_INITIALIZER<\/h2>\n
    Some libraries used the constructor of lazy NgModule<\/code> for their initialization. To further support this approach without NgModule<\/code>s, there is now the concept of an ENVIRONMENT_INITIALIZER<\/code>:<\/p>\n
    export const FLIGHT_BOOKING_ROUTES: Routes = [{\n    path: '',\n    component: FlightBookingComponent,\n    providers: [\n        importProvidersFrom(StoreModule.forFeature(bookingFeature)),\n        importProvidersFrom(EffectsModule.forFeature([BookingEffects])),\n        {\n            provide: ENVIRONMENT_INITIALIZER,\n            multi: true,\n            useValue: () => inject(InitService).init()\n        }\n    ],\n    children: [\n        [...]\n    ]\n}<\/code><\/pre>\n
    Basically, the ENVIRONMENT_INITIALIZER<\/code> provides a function executed when the Environment Injector is initialized. The flag multi: true<\/code> already indicates that you can have several such initializers per scope.<\/p>\n
    What's next? More on Architecture!<\/h2>\n
    So far, we've seen how to decompose a huge client into several libraries with Standalone Components. However, when dealing with enterprise-scale frontends, several additional questions come in mind:<\/p>\n