Summary

Today I’m wrapping up my series of articles looking at Angular Elements. Here’s a quick recap.

• Part 1 – What is an Angular Element? What is a Custom Element?
• Part 2 – How to add Angular Element support to a project
• Part 3 – How to turn an Angular Component into an Angular Element
• Part 4 – How to add an Angular Element to any webpage, outside of an Angular project

I’m pretty excited about Angular Elements. They solve a real-world problem which affects many developers. Before Angular 6, even the official Angular website had to find workarounds.

The official documentation website, angular.io, uses Angular Elements. Head over there to see Angular Elements in the wild.

Use Cases

• Enhancing Existing Applications
  • much easier to write dynamic components
  • server-side rendering / hybrid rendering
• Element Containers
  • packaging up a mini-application and using it in different containers
  • sprinkling components throughout a site
  • CMS
• Re-usable Widgets
  • Cross framework compatibility
  • build once, use anywhere

Future

Angular Elements are ready for primetime but suffer from a lack of CLI support and large package size.

The Angular CLI is already being worked on. A customised build process for Angular Elements will be available soon.

The next version of Angular will include a new rendering engine called Ivy. It will bring minimum package sizes down from 36K to less than 3K.

The Ivy renderer will reduce the amount of boilerplate required to write an Element. A simple switch on the @Component directive will be all you need. e.g. customElement: true. You won’t need to fiddle with app.module.ts.

A tweak to the Javascript API will allow us to inject dependencies into the constructor. A cool use case for this is sharing state (e.g. redux) between individual elements on a single page.

So what do you think? Hit reply. I’d love to know if you plan to use Angular Elements.

<< Read part 4