{"id":6180,"date":"2022-05-07T20:08:00","date_gmt":"2022-05-07T18:08:00","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=6180"},"modified":"2024-01-19T15:37:29","modified_gmt":"2024-01-19T14:37:29","slug":"module-federation-with-angulars-standalone-components","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/module-federation-with-angulars-standalone-components\/","title":{"rendered":"Module Federation with Angular’s Standalone Components"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 9 of 10 in the series “Module Federation”<\/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. The Microfrontend Revolution: Module Federation in Webpack 5<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  2. The Microfrontend Revolution: Module Federation with Angular<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  3. Dynamic Module Federation with Angular<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  4. Building A Plugin-based Workflow Designer With Angular and Module Federation<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  5. Getting Out of Version-Mismatch-Hell with Module Federation<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  6. Using Module Federation with (Nx) Monorepos and Angular<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  7. Pitfalls with Module Federation and Angular<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  8. Multi-Framework and -Version Micro Frontends with Module Federation: Your 4 Steps Guide<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  9. Module Federation with Angular’s Standalone Components<\/span><\/li>\n\t\t\t\t\t\t\t\t\t
  10. What’s New in our Module Federation Plugin 14.3?<\/a><\/li>\n\t\t\t\t\t\t\t<\/ol>\n\t\t<\/div>\n\t<\/div>\n

    Most tutorials on Module Federation and Angular expose Micro Frontends in the form of NgModules. However, with the introduction of Standalone Components we will have lightweight Angular solutions not leveraging NgModules anymore. This leads to the question: How to use Module Federation in a world without NgModules?<\/p>\n<\/p>\n

    In this article, I give answers. We see both, how to expose a bunch of routes pointing to Standalone Components and how to load an individual Standalone Component. For this, I've updated my example to fully work without NgModules:<\/p>\n

    \"The<\/p>\n

    Please find the \ud83d\udcc2 source code here<\/a> (branch: standalone-solution).<\/p>\n

    Router Configs vs. Standalone Components<\/h2>\n

    In general, we could directly load Standalone Components via Module Federation. While such a fine-grained integration seems to be fine for plugin-systems, Micro Frontends are normally more coarse-grained. It's usual that they represent a whole business domain which in general contains several use cases belonging together.<\/p>\n

    Interestingly, Standalone Components belonging together can be grouped using a router config. Hence, we can expose and lazy load such router configurations.<\/p>\n

    Initial Situation: Our Micro Frontend<\/h2>\n

    The Micro Frontend used here is a simple Angular application bootstrapping a Standalone Component:<\/p>\n

     \/\/ projects\/mfe1\/src\/main.ts\n\n import { environment } from '.\/environments\/environment';\n import { enableProdMode, importProvidersFrom } from '@angular\/core';\n import { bootstrapApplication } from '@angular\/platform-browser';\n import { AppComponent } from '.\/app\/app.component';\n import { RouterModule } from '@angular\/router';\n import { MFE1_ROUTES } from '.\/app\/mfe1.routes';\n\n if (environment.production) {\n   enableProdMode();\n }\n\n bootstrapApplication(AppComponent, {\n   providers: [\n     importProvidersFrom(RouterModule.forRoot(MFE1_ROUTES))\n   ]\n });<\/code><\/pre>\n
    When bootstrapping, the application registers its router config MFE1_ROUTES<\/code> via services providers. This router config points to several Standalone Components:<\/p>\n
     \/\/ projects\/mfe1\/src\/app\/mfe1.routes.ts\n\n import { Routes } from '@angular\/router';\n import { FlightSearchComponent } from '.\/booking\/flight-search\/flight-search.component';\n import { PassengerSearchComponent } from '.\/booking\/passenger-search\/passenger-search.component';\n import { HomeComponent } from '.\/home\/home.component';\n\n export const MFE1_ROUTES: Routes = [\n     {\n         path: '',\n         component: HomeComponent,\n         pathMatch: 'full'\n     },\n     {\n         path: 'flight-search',\n         component: FlightSearchComponent\n     },\n     {\n         path: 'passenger-search',\n         component: PassengerSearchComponent\n     }\n ];<\/code><\/pre>\n
    Here, importProvidersFrom<\/code> bridges the gap between the existing RouterModule<\/code> and the world of Standalone Components. As a replacement for this, future versions of the router will expose a function for setting up the router's providers. According to the underlying CFP, this function will be called configureRouter<\/code>.<\/p>\n
    The shell used here is just an ordinary Angular application. Using lazy loading, we are going to make it reference the Micro Frontend at runtime.<\/p>\n
    Activating Module Federation<\/h2>\n
    To get started, let's install the Module Federation plugin and activate Module Federation for the Micro Frontend:<\/p>\n
    npm i @angular-architects\/module-federation\n\n ng g @angular-architects\/module-federation:init --project mfe1 --port 4201 --type remote<\/code><\/pre>\n
    This command generates a webpack.config.js<\/code>. For our purpose, we have to modify the exposes<\/code> section as follows:<\/p>\n
     const { shareAll, withModuleFederationPlugin } = require("@angular-architects\/module-federation\/webpack");\n\n module.exports = withModuleFederationPlugin({\n   name: "mfe1",\n\n   exposes: {\n     \/\/ Preferred way: expose corse-grained routes\n     ".\/routes": ".\/projects\/mfe1\/src\/app\/mfe1.routes.ts",\n\n     \/\/ Technically possible, but not preferred for Micro Frontends:\n     \/\/ Exposing fine-grained components\n     ".\/Component": ".\/projects\/mfe1\/src\/app\/my-tickets\/my-tickets.component.ts",\n   },\n\n   shared: {\n     ...shareAll({ singleton: true, strictVersion: true, requiredVersion: "auto" }),\n   }\n\n });<\/code><\/pre>\n
    This configuration exposes both, the Micro Frontend's router configuration (pointing to Standalone Components) and a Standalone Component.<\/p>\n
    Static Shell<\/h2>\n
    Now, let's also activate Module Federation for the shell. In this section, I focus on Static Federation. This means, we are going to map the paths pointing to our Micro Frontends in the webpack.config.js. <\/p>\n
    \n
    The next section shows how to switch to Dynamic Federation, where we can define the key data for loading a Micro Frontend at runtime.<\/p>\n<\/blockquote>\n
    To enable Module Federation for the shell, let's execute this command:<\/p>\n
    ng g @angular-architects\/module-federation:init --project shell --port 4200 --type host<\/code><\/pre>\n
    The webpack.config.js<\/code> generated for the shell needs to point to the Micro Frontend:<\/p>\n
     const { shareAll, withModuleFederationPlugin } = require("@angular-architects\/module-federation\/webpack");\n\n module.exports = withModuleFederationPlugin({\n\n   remotes: {\n     "mfe1": "http:\/\/localhost:4201\/remoteEntry.js",\n   },\n\n   shared: {\n     ...shareAll({ singleton: true, strictVersion: true, requiredVersion: "auto" }),\n   }\n\n });<\/code><\/pre>\n
    As we are going with static federation, we also need typings for all configured paths (EcmaScript modules) referencing Micro Frontends:<\/p>\n
     \/\/ projects\/shell\/src\/decl.d.ts\n\n declare module 'mfe1\/*';<\/code><\/pre>\n
    Now, all it takes is a lazy route in the shell, pointing to the routes and the Standalone Component exposed by the Micro Frontend:<\/p>\n
     \/\/ projects\/shell\/src\/app\/app.routes.ts\n\n import { Routes } from '@angular\/router';\n import { HomeComponent } from '.\/home\/home.component';\n import { NotFoundComponent } from '.\/not-found\/not-found.component';\n import { ProgrammaticLoadingComponent } from '.\/programmatic-loading\/programmatic-loading.component';\n\n export const APP_ROUTES: Routes = [\n     {\n       path: '',\n       component: HomeComponent,\n       pathMatch: 'full'\n     },\n\n     {\n       path: 'booking',\n       loadChildren: () => import('mfe1\/routes').then(m => m.BOOKING_ROUTES)\n     },\n\n     {\n       path: 'my-tickets',\n       loadComponent: () => \n           import('mfe1\/Component').then(m => m.MyTicketsComponent)\n     },\n\n     [...]\n\n     {\n       path: '**',\n       component: NotFoundComponent\n     }\n ];<\/code><\/pre>\n
    Alternative: Dynamic Shell<\/h2>\n
    Now, let's move to dynamic federation. Dynamic Federation means, we don't want to define our remote upfront in the shell's webpack.config.js<\/code>. Hence, let's comment out the remote section there:<\/p>\n
     const { shareAll, withModuleFederationPlugin } = require("@angular-architects\/module-federation\/webpack");\n\n module.exports = withModuleFederationPlugin({\n\n   \/\/ remotes: {\n   \/\/   "mfe1": "http:\/\/localhost:4201\/remoteEntry.js",\n   \/\/ },\n\n   shared: {\n     ...shareAll({ singleton: true, strictVersion: true, requiredVersion: "auto" }),\n   }\n\n });<\/code><\/pre>\n
    Also, in the shell's router config, we need to switch out the dynamic imports<\/code> used before by calls to loadRemoteModule<\/code>:<\/p>\n
     \/\/ projects\/shell\/src\/app\/app.routes.ts\n\n import { Routes } from '@angular\/router';\n import { HomeComponent } from '.\/home\/home.component';\n import { NotFoundComponent } from '.\/not-found\/not-found.component';\n import { ProgrammaticLoadingComponent } from '.\/programmatic-loading\/programmatic-loading.component';\n import { loadRemoteModule } from '@angular-architects\/module-federation';\n\n export const APP_ROUTES: Routes = [\n     {\n       path: '',\n       component: HomeComponent,\n       pathMatch: 'full'\n     },\n     {\n       path: 'booking',\n       loadChildren: () => \n         loadRemoteModule({\n           type: 'module',\n           remoteEntry: 'http:\/\/localhost:4201\/remoteEntry.js',\n           exposedModule: '.\/routes'\n         })\n         .then(m => m.MFE1_ROUTES)\n     },\n     {\n       path: 'my-tickets',\n       loadComponent: () => \n         loadRemoteModule({\n           type: 'module',\n           remoteEntry: 'http:\/\/localhost:4201\/remoteEntry.js',\n           exposedModule: '.\/Component'\n         })\n         .then(m => m.MyTicketsComponent)\n     },\n     [...]\n     {\n       path: '**',\n       component: NotFoundComponent\n     }\n ];<\/code><\/pre>\n
    The loadRemoteModule<\/code> function takes all the key data, Module Federation needs for loading the remote. This key data is just several strings, hence you can load it from literally everywhere.<\/p>\n
    Bonus: Programmatic Loading<\/h2>\n
    While most of the times, we will load Micro Frontends (remotes) via the router, we can also load exposed components programmatically. For this, we need a placeholder marked with a template variable for the component in question:<\/p>\n
     <h1>Programmatic Loading<\/h1>\n\n <div>\n     <button (click)="load()">Load!<\/button>\n <\/div>\n\n <div #placeHolder><\/div><\/code><\/pre>\n
    We get hold of this placeholder's ViewContainer<\/code> via the ViewChild<\/code> decorator:<\/p>\n
     \/\/ projects\/shell\/src\/app\/programmatic-loading\/programmatic-loading.component.ts\n\n import { Component, OnInit, ViewChild, ViewContainerRef } from '@angular\/core';\n\n @Component({\n   selector: 'app-programmatic-loading',\n   standalone: true,\n   templateUrl: '.\/programmatic-loading.component.html',\n   styleUrls: ['.\/programmatic-loading.component.css']\n })\n export class ProgrammaticLoadingComponent implements OnInit {\n\n   @ViewChild('placeHolder', { read: ViewContainerRef })\n   viewContainer!: ViewContainerRef;\n\n   constructor() { }\n\n   ngOnInit(): void {\n   }\n\n   async load(): Promise<void> {\n\n       const m = await import('mfe1\/Component');\n       const ref = this.viewContainer.createComponent(m.MyTicketsComponent);\n       \/\/ const compInstance = ref.instance;\n       \/\/ compInstance.ngOnInit()\n   }\n\n }<\/code><\/pre>\n
    This example shows a solution for Static Federation. Hence a dynamic import<\/code><\/code> is used for getting hold of the Micro Frontend.<\/p>\n
    After importing the remote component, we can instantiate it using the ViewContainer<\/code>'s createComponent<\/code> method. The returned reference (ref) points to the component instance with it's instance<\/code> property. The instance allows to interact with the component, e. g. to call methods, set property, or setup event handlers.<\/p>\n
    If we wanted to switch to Dynamic Federation, we would again use loadRemoteModule<\/code> instead of the dynamic <\/code>import<\/code><\/code>: <\/p>\n
     async load(): Promise<void> {\n\n     const m = await loadRemoteModule({\n       type: 'module',\n       remoteEntry: 'http:\/\/localhost:4201\/remoteEntry.js',\n       exposedModule: '.\/Component'\n     });\n\n     const ref = this.viewContainer.createComponent(m.MyTicketsComponent);\n     \/\/ const compInstance = ref.instance;\n }<\/code><\/pre>\n
    What's next? More on Architecture!<\/h2>\n
    So far, we've seen how to decompose a huge client into several Micro Frontends that can even use different frameworks. However, when dealing with enterprise-scale frontends, several additional questions come in mind:<\/p>\n