Angular Elements Advanced Techniques

Source code for Angular Elements Advanced Techniques on Github

It is exciting to finally see the adoption of web components going mainstream. There are many tools available for building them, but none can match the power and stability of Angular Elements. The following lesson will provide a handful of useful techniques aimed at building complex production-ready custom elements.

In addition to this post, check out these resources:

• Manfred Steyer’s Angular Elements Series
• Sam Julian’s Getting Started with Angular Elements
• Nrwl’s Five Reasons to Use Angular Elements
• Angular Elements QuickStart

Rendering without Zone.JS

After much experimentation, I’ve come to the conclusion that Zone.JS is not the the ideal way to handle change detection with Angular Elements. Automatic change detection is awesome when working in the context of an Angular app, but when you decouple your Angular components as custom elements you can run into hard-to-debug issues that only seem to happen in production. The Angular team has several open issues to address these bugs, but I think moving away from zones is a smart move in general. You will need to manually tell Angular when to re-render your components (see next sections), but this actually makes your code more explicit and easier to understand.

First, let’s turn off zones globally in the main.ts file.

// omitted ...
platformBrowserDynamic().bootstrapModule(AppModule, { ngZone: 'noop'})

You can also turn zones off at the component level by setting the OnPush strategy.

@Component({
  // ...
  changeDetection: ChangeDetectionStrategy.OnPush,
})

Component State

Now that zones are switched off, we need Angular to render the component when its internal data changes The general idea here is not novel and is similar conceptually in React, Flutter, and Stencil - i.e one way data flow. We have a state object that when changed with the setState(key, value) method tells the component to render - simple.

import { Component, ChangeDetectorRef } from '@angular/core';

@Component(...)
export class ImgLazyComponent {

 // Only modify with setState
  state = {
    visible: false,
    loaded: false
  };

  constructor(private cd: ChangeDetectorRef) {}

  private setState(key, value) {
    this.state = { ...this.state, [key]: value };
    this.cd.detectChanges();
  }

  // Usage
  show() {
    this.setState('visible', true);
  }
}

Keep in mind, there are many ways you could implement this code. The only secret sauce is the call to this.cd.detectChanges().

Shared Global State

One of the ways Angular Elements stands out is its ability to share data and functionality between components via dependency injection.

ng g service shared

To run change detection in a shared service, we reference the entire application, then call tick whenever an shared value changes.

import { Injectable, ApplicationRef } from '@angular/core';

@Injectable()
export class CoolService {
  state = 0;

  constructor(private app: ApplicationRef) {}

  setState() {
    this.state = Math.random();

    // Run change detection
    this.app.tick();
  }
}

Page Load Performance

One of the main criticisms of Angular Elements has been the bundle size, which is around 60Kb for a gzipped hello world. (1) The bundle size will decrease significantly when Ivy lands in the near future. (2) You’re getting the full power of Angular in that bundle, and (3) it does not have a significant impact on perf when you defer the script.

When you defer a script tag <script defer src="elements.js"> it tells the browser to render the HTML first, then load the script - i.e no render blocking. This is crucial for static websites the use components because your top priority is getting the main content painted. After the first meaningful paint, your web components can kick in to add interactivity.

The tests below were run with a bundle containing both Angular and Firebase at a weight of 350Kb.

Notice how we’re getting a page load of 600ms ⚡ - 4x faster - and a near perfect performance score. That is awesome considering how much horsepower we have under the hood.

Register Multiple Custom Elements

In most projects, you will have more than one component and it is cumbersome to register them one-by-one. I prefer to create an array of arrays (or tuples if you will) with the config for each element, then register them in a loop.

export class AppModule {
  constructor(private injector: Injector) {

    const elements: any[] = [
      [ImgLazyComponent, 'img-lazy'],
      [ImgFirebaseComponent, 'img-firebase'],
      [MyBtnComponent, 'my-btn']
    ];

    for (const [component, name] of elements) {
      const el = createCustomElement(component, { injector: this.injector });
      customElements.define(name, el);
    }
  }

  ngDoBootstrap() {}
}

Exposing Public Methods

A beautiful thing about web components is that we can interact with them using vanilla JS (or within other frameworks). By default, your internal code will not be accessible to the outside world, for example:

document.querySelector('my-element').cool();
// undefined

But it can be useful to allow non-angular code to control your elements. Methods and properties can be exposed using the @Input decorator. One caveat is that in order to give your element the proper this context, you need make public methods a function property like so:

@Input()
notCool() { console.log(this.state) }
// this == undefined


@Input()
cool = () => console.log(this.state)
// this == ComponentInstance

Exposing Public Events

You might also want to listen to the the custom events emitted by your component, for example:

document.querySelector('my-element').addEventListener('my-custom-event', (e) => doSomething)

We can make this happen by dispatching a CustomEvent in the browser alongside an Angular Output/EventEmitter combo.

@Component(...)
export class ImgLazyComponent {

  @Output() coolEvent = new EventEmitter();

  constructor(private el: ElementRef) {}

  private customEmit(val) {
    this.coolEvent.emit(val);
    const domEvent = new CustomEvent('cool-event');
    this.el.nativeElement.dispatchEvent(domEvent);
  }

  doSomething() {
    this.customEmit('did something');
  }
}

Content Projection and Shadow DOM

One cannot just embed HTML inside a custom element. Currently, if you try to transclude some markup in your web component it will be removed.

<my-element>

  <!-- You won't see this -->
  <h1>Howdy, Partner</h1>

</my-element>

You can save your end users the hassle of adding their own custom markup by projecting content into slots. This feature requires the Shadow DOM to be enabled in your component.

@Component({
  // ...
  encapsulation: ViewEncapsulation.ShadowDom
})

Now you can add slots to your component markup.

Default Slot

If you only have one place for the user to project markup, you can simply add a default slot.

<!-- Component HTML -->
<img src="...">
<slot></slot>

Now HTML can be included inside the component and will be rendered below the image.

<!-- Usage -->
<my-element>
  <h1>My Cool Image</h1>
</my-element>

Named Slots

<!-- Component HTML -->
<h1><slot name="header">Default Header</slot></h1>
<p><slot name="caption">Default Caption</slot></p>

Now the end user of the web component can just pass a span that references the slot name and it will be rendered in the matching location.

<!-- Usage -->
<my-element>
  <span slot="caption">I ❤️ Web Components</span>
  <span slot="header">My Custom Header</span>
</my-element>