Why you should care about Angular Elements
Over the past months, there has been a huge hype going on within the development world about Web Components, Progressive Web Apps (PWAs) and lookalike. With the release of Angular 6, the Angular team has introduced Web Components into the framework and hence caused an almost equally huge hype within the Angular community.
The goal of this post is to give you a clear introduction to the topic, unfold some of the use cases of Web Components within Angular, and (most importantly) explain to you what this huge hype is all about.
NOTE: Web Components within Angular are still in their alpha state. Important changes might ship with the next version of Angular regarding usability and integration. Nevertheless, it is definitely worth taking a look at how they work and explore some of the features that are available already.
Why Web Components matter
To give a low-level explanation: Web Components allow us to reuse parts of what we’ve written without having to copy hundreds of lines of code into an index.html file that is already bursting at the seams.
By the use of Web Components, we can define our own custom html-tags. Each of which contains its own embedded business logic, styles, and possible child components. They allow us to divide our application into small responsibility-oriented chunks without having to worry about style bleeding or internal naming conflicts.
Also, the deployed Web Components are self-bootstrapping, meaning they contain all the code and dependencies required for them to work. This makes Web Components not only easy to use, but easy to test and maintain as well, since you only have to make changes in your code once.
Best of all: Web Components are framework-agnostic. It doesn’t matter whether your current project is based on Angular, React, or plain HTML — since Web Components contain all the logic and dependencies within themselves, they work no matter which framework you use.
Why bother with Angular?
With the release of Angular 6, the Angular team gave developers the opportunity to export their Angular Components as Web Components, offering them all the advantages of Web Components while still being able to use Angular’s reactive approach behind the scenes. Two-way binding, event listening, and dependency injection still work the way they used to before. Only now you don’t have to build a Single Page Application to use those features.
During development, programmers can make use of the advantages the Angular eco system offers, like an embedded testing environment or dependency management via npm, while on the other hand not being forced to build the whole project in Angular.
But what if you’re already using Angular in your project? Is it possible to revise your code so that your Angular components can be used as Web Components? Well, the Angular team did just that. As a showcase, they rebuilt the official Angular website using their already existing Angular components as Web Components. If you are interested in taking a peek, check it out at next.angular.io!
Code Example
In the picture below you can see the component I built and exported as Web Component in order to test Angular Elements first hand. The goal was to create a component that takes a picture url and some other styling properties as inputs and displays a custom text whenever the user hovers over it.
To view the source code visit https://github.com/selfbits/angular-webcomponent-example.
Setting up the TypeScript File
The TypeScript code for the Info-Image-Component has been written just like any other Angular component. In the beginning I declared the variables for data binding. In the constructor method Renderer2 was injected. And underneath ngOnInit I defined some methods to either display or hide the description set via property binding.
Since the Angular-specific view encapsulation won’t be available outside of Angulars ecosystem by default, I had to explicitly declare which encapsulation mode I would like to use, in this case: ViewEncapsulation.Native.
Setting up the HTML
As with the TypeScript file, the HTML code looks and works just like any other component. Property binding enables me to manipulate the underlying elements depending on the properties I defined, while event binding triggers the displayDescription- and hideDescription-methods.
Deployment
If you are interested in the deployment process of Web Components in Angular as of now, I highly recommend Sebastian Eschweilers article. Sebastian did a great job at explaining the build process in a step-by-step guide while elaborating some of the backgrounds in between.
Importing the deployed Web Component
After deployment, I set up a simple html file to see the Info-Image Web Component in action. All I had to do was importing the compiled JavaScript file and declaring the component alike any other HTML element. Ready. Done. That was all.
The Future of Angular Elements (probably)
At the moment, the production build for Web Components seems slightly over-complicated writing your own npm-scripts and so forth. As Rob Wormald explained at the ng-conf, the Angular team is working on providing a much simpler way to develop and deploy Web Components via Angular.
As always, one point of criticism Angular has to face, when being compared to React or Vue, is its bundle size. Angular Elements are no exception. You wouldn’t want your custom elements to be 5 MB large, since larger bundle sizes mean higher loading time leading to worse user experience.
A gleam of hope ships with ivy. The revised rendering process in align with an optimised tree shaking procedure promises to reduce bundle sizes up to 7% of the original size. For example, a simple hello world application with a bundle size of currently 36 Kb would only take up about 2.7 Kb when rendered with Ivy. Help is on the way!
Conclusion
To sum things up, Angular Elements might be the beginning of a great journey towards a framework-agnostic world, where the focus does not rest on whether the development team used Angular or React, but whether the user had a pleasant experience using the application.
Current developments like Web Components might soon enable us to use the advantages of each framework or library in a context where it makes sense without being forced into a project structure just because it ships with the framework.
No matter what the future will bring, it’s sure going to be exciting.
