Because of this we can often face situation when we are running different versions of the same widget in various apps which may cause other problems related to breaking changes with relation to backend APIs, incompatible data, or myriad other things…

Wouldn’t it be great if we could deploy new version of our widget independently from release cycle of consumer applications?

This is exactly what is enabled by the use of Angular elements! The “sub-application” element is released and deployed independently as a single file bundle which is then referenced ONLY by the url in the consumer apps.

To make referencing easier, the bundle file name can always stay the same (for example some-element.js without any hash) for every version of the element. The cache busting is then handled with the help of etag which is transparently calculated based on the file content on the server. Learn more about ETag HTTP response headers.

Follow me on Twitter because you will get notified about new Angular blog posts and cool frontend stuff!😉

2. On-demand loading of a heavy 3rd party component

Let’s say we are building an Angular application and we are paying extra attention to architecture of the features making them nicely isolated and lazy loaded. The performance, maintainability and start up time of our application is great!

Then there is this new requirement to add possibility to inline edit every item of a large list using a powerful (but also very heavy) rich text editor.

As a result the size and hence loading of that feature will suffer even though the editor is only displayed as a result of user interaction and never from the start.

Now to be fair, Angular does support lazy loading of the components but it is not such a great developer experience just yet…

On the other hand granular lazy loading of the Angular elements can be extremely easy!

Cool, we have seen that the elements could really help us in some of the common situations which can be encountered in most enterprise organizations…

Building and serving Angular elements

As teased in section above, Angular elements is basically an Angular application which uses createCustomElement() function from the @angular/elements package to wrap standard Angular components and make them available as native custom elements…

This means we can leverage Angular CLI to build our elements projects the same way as any other Angular application!

But hey, Angular CLI produces quite a number of bundle files which doesn’t sound too practical for referencing them in the consumer apps…

This is a real concern and it can be addressed by using amazing ngx-build-plus library by Manfred Steyer. It enable us to use --single-bundle flag when running ng build command and as suggested by its name, it produces a single bundle file!

Also, we will be using --outputHashing none flag to keep the bundle file name the same! This is because we want consumers to be able to reference our element without the need to update that reference for every new release of the element.

Putting hash in the element file name would defeat the original purpose of getting independent release cycles!

This leaves us with two main options. Either we use very short HTTP cache expiry times or go with the ETags depending on the use case and the expected release cadence…

The elements bundle then can be served by any HTTP server or CDN!

How to consume elements in our Angular applications

Good! Our element is out there somewhere, available on some url so the only thing left is to use it in our application!

1. The standard way of consuming elements or any other web components

Being a Javascript bundle, the most straight forward way to consume an element would be to simply include <script> tag in the <head> of our page to make sure that the element was downloaded and registered before the first occurrence of its tag in the <body> …

This might make sense for elements that we want to use straight from the get go but usually it is better to postpone loading of the element bundle until the last possible moment before it is used!

2. The best way of consuming elements or any other web components

Now, we said we’re focusing on consuming elements in the context of parent Angular applications…

This means that we have all the great Angular features at our disposal, one of them being structural directives!

Structural directives are directives prefixed with the * character, the most famous one being *ngIf .

The * is “syntactic sugar” for something a bit more verbose. It changes the underlying page structure by wrapping of the host element with the <ng-template> element effectively removing it from the DOM.

This is very helpful because it enables us to implement mechanism that removes element tag from the DOM and only adds it back after we loaded the element bundle!

Such a directive would at least have to…

remove element tag from the DOM add <script> tag with elements bundle url to the body wait for the bundle to be loaded add element back to the DOM