{"id":22889,"date":"2023-10-09T17:07:47","date_gmt":"2023-10-09T15:07:47","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=22889"},"modified":"2025-01-11T19:06:52","modified_gmt":"2025-01-11T18:06:52","slug":"micro-frontends-with-modern-angular-part-2-multi-version-and-multi-framework-solutions-with-angular-elements-and-web-components","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/micro-frontends-with-modern-angular-part-2-multi-version-and-multi-framework-solutions-with-angular-elements-and-web-components\/","title":{"rendered":"Micro Frontends with Modern Angular – Part 2: Multi-Version and Multi-Framework Solutions with Angular Elements and Web Components"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 2 of 6 in the series “Micro Frontends with Modern Angular”<\/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. Micro Frontends with Modern Angular – Part 1: Standalone and esbuild<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  2. Micro Frontends with Modern Angular – Part 2: Multi-Version and Multi-Framework Solutions with Angular Elements and Web Components<\/span><\/li>\n\t\t\t\t\t\t\t\t\t
  3. Combining Native Federation and Module Federation<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  4. SSR and Hydration with Native Federation for Angular<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  5. Fixing DX Friction: Automatic Shell Reloading in Native Federation<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  6. Native Federation Just Got Better: Performance, DX, and Simplicity<\/a><\/li>\n\t\t\t\t\t\t\t<\/ol>\n\t\t<\/div>\n\t<\/div>\n

    The first part of this article series showed how to use modern Angular with Native Federation and esbuild. We've assumed that all Micro Frontends and the shell use the same framework in the same version. However, if the goal is to integrate Micro Frontends that are based on different frameworks and\/or framework versions, you need some additional considerations.<\/p>\n

    As discussed in this blog article<\/a>, such an approach is nothing you normally want to introduce without a good reason like dealing with legacy systems or combining existing products to a suite.<\/p>\n

    \ud83d\udcc2 Source Code<\/a>
    \n(see branch nf-web-comp-mixed<\/code>)<\/p>\n

    Abstracting Micro Frontends with Web Components<\/h2>\n

    The first step when implementing such a scenario is abstracting the different frameworks and versions. A popular way for this is to use Web Components that encapsulate entire Micro Frontends. The result is not a ideal-typical Web Components in the sense of reusable widgets, but rather a coarse-grained web components that represent entire domains. The following image shows a Web Component bootstrapping a React application that is loaded into an Angular-based shell:<\/p>\n

    \"React-Micro<\/p>\n

    Actually, it's not difficult to write a Web Component that delegates to a framework instead of writing something into the DOM itself. Angular makes even this task easier with the @angular\/elements converting an Angular component into a Web Component. Technically speaking, it wraps the Angular Component into a Web Component created on the fly.<\/p>\n

    The package @angular\/elements can be installed with npm (npm i @angular\/elements<\/code>). Together with Standalone Components, it's used in a straight forward manner:<\/p>\n

    import { NgZone } from '@angular\/core';\n\n(async () => {\n  const app = await createApplication({\n    providers: [\u2026],\n  });\n\n  const mfe2Root = createCustomElement(AppComponent, {\n    injector: app.injector,\n  });\n\n  customElements.define('mfe2-root', mfe2Root);\n})();<\/code><\/pre>\n
    The lines of code shown here replace bootstrapping the application. The createApplication<\/code> function creates an Angular application including a root injector. The latter is configured via the providers<\/em> array. However, instead of bootstrapping a component, createCustomElement<\/code> transforms a standalone component into a web component.<\/p>\n
    The customElements.define<\/code> method is already part of the browser's API and registers the Web Component under the name mfe2-root<\/code>. This means that from now on the browser will render the web component and thus the Angular component behind it as soon as <mfe2-root><\/mfe2-root><\/code> appears in the markup. When assigning the name, please note that by definition it must contain a hyphen. This is to avoid naming conflicts with existing HTML elements.<\/p>\n
    In order to share this Web Component via Native Federation, the file defining the Web Component must be specified in the federation.config.js<\/code> under exposes<\/code>. In the case considered here, this is bootstrap.ts<\/code>:<\/p>\n
    exposes: {\n  '.\/web-components': '.\/projects\/mfe2\/src\/bootstrap.ts',\n},<\/code><\/pre>\n
    This approach gives us the best of both worlds: Using Native Federation, frameworks and libraries can be shared as long as multiple Micro Frontends use the same version. By abstracting differences via Web Components, different frameworks and framework versions can also be integrated:<\/p>\n
    \"Web<\/p>\n
    Loading Web Components in a Shell<\/h2>\n
    Providing a Web Component via Native Federation is only one side of the coin: We also have to load the Web Component into a shell. Since the Angular Router can only work with Angular Components, it makes sense to wrap our Web Components into an Angular Component:<\/p>\n
    import { loadRemoteModule } from '@softarc\/native-federation-runtime';\n\n@Component({\n  selector: 'app-wrapper',\n  standalone: true,\n  imports: [CommonModule],\n  templateUrl: '.\/wrapper.component.html',\n  styleUrls: ['.\/wrapper.component.css']\n})\nexport class WrapperComponent implements OnInit {\n  elm = inject(ElementRef);\n\n  async ngOnInit() {\n    await loadRemoteModule('mfe2', '.\/web-components');\n    const root = document.createElement('mfe2-root');\n    this.elm.nativeElement.appendChild(root);\n  }\n}<\/code><\/pre>\n
    This WrapperComponent<\/code> loads the Web Component via Native Federation and creates an HTML element into which the browser renders the Web Component. To simplify things, the key data used for this -- the names mfe2<\/code>, .\/web-components<\/code> and mfe2-root<\/code> -- are hard-coded in the example shown. In order to make the WrapperComponent<\/code> universally applicable, it is advisable to make this information parameterizable, e. g. via an @Input:<\/p>\n
    @Component([...])\nexport class WrapperComponent implements OnInit {\n  elm = inject(ElementRef);\n\n  @Input() config = initWrapperConfig;\n\n  async ngOnInit() {\n    const { exposedModule, remoteName, elementName } = this.config;\n\n    await loadRemoteModule(remoteName, exposedModule);\n    const root = document.createElement(elementName);\n    this.elm.nativeElement.appendChild(root);\n  }\n}<\/code><\/pre>\n
    The constant initWrapperConfig<\/code> and its underlying type is defined as follows:<\/p>\n
    export interface WrapperConfig {\n    remoteName: string;\n    exposedModule: string;\n    elementName: string;\n}\n\nexport const initWrapperConfig: WrapperConfig = {\n    remoteName: '',\n    exposedModule: '',\n    elementName: '',\n}<\/code><\/pre>\n
    It's also noteworthy that since Angular 16, the router can directly bind routing parameters to an @Input. For this, activate the following feature during bootstrap:<\/p>\n
    bootstrapApplication(AppComponent, {\n  providers: [\n    provideRouter(\n      APP_ROUTES, \n      withComponentInputBinding()\n    )\n  ],\n});<\/code><\/pre>\n
    This allows routes as the following:<\/p>\n
    export const APP_ROUTES: Routes = [\n  [...],\n  {\n    path: 'passengers',\n    component: WrapperComponent,\n    data: {\n      config: {\n        remoteName: 'mfe2',\n        exposedModule: '.\/web-components',\n        elementName: 'mfe2-root',\n      } as WrapperConfig,\n    },\n  },\n  [...]\u00b4\n];<\/code><\/pre>\n
    Sharing Zone.js<\/h2>\n
    Angular currently still uses Zone.js<\/em> for change detection. The NgZone<\/code> service represents Zone.js<\/code> within Angular. To avoid problems, you should ensure that all Micro Frontends and the shell use the same NgZone<\/code> instance. To achieve this, the shell's AppComponent<\/code> could share its NgZone<\/code> across the global namespace:<\/p>\n
    @Component([\u2026])\nexport class AppComponent {\n  constructor() {\n      globalThis.ngZone = inject(NgZone);\n  }\n}<\/code><\/pre>\n
    The individual Micro Frontends can then use this instance during bootstrapping:<\/p>\n
    const app = await createApplication({\n  providers: [\n    globalThis.ngZone ? { provide: NgZone, useValue: globalThis.ngZone } : [],\n    provideRouter(APP_ROUTES),\n  ],\n});<\/code><\/pre>\n
    Fortunately, with Signals we are looking into a Zone-less future and once Angular works without Zone.js<\/em> we can git rid of this workaround.<\/p>\n
    Web Components with own Routes<\/h2>\n
    Things get a little more exciting when the micro frontend of the web component also uses routing. In this case, two routers duel over the URL - the shell's router and the Micro Frontend's router:<\/p>\n
    \"Micro<\/p>\n
    To ensure that the two routers do not interfere with each other, the following procedure has proven to be effective:<\/p>\n