Angular Elements vs Angular Library?

Question

My team works with multiple angular projects. For code reuse, we have a lot of presentational components extracted into libraries, which we then use in our various projects.

So, given that all our projects are on angular, and we already use libraries, what more can we get from angular elements?

The reason i started looking into elements is:

Most of our older projects are working with Bootstrap 3. We would want to use Bootstrap 4 with the new things we make. So I was wondering if an element could be designed with Bootstrap 4, and use it somewhere that was designed with B-3 without things breaking ?

Is that possible ?

Custos

Answer 1

First your second question.
Yes it is possible to design your new elements with Bootstrap 4. This is one of the benefits of Web Components (Angular Elements), that you get style encapsulation inside your shadow tree.

If your goal is to create really self contained elements, the downside is, that you will have to include Boostrap in every Angular Element.

Just out of curiosity I created a new Angular project (ng new), created a Angular Element out of it containing Boostrap 4 and checked the size with Webpack Bundle Analyzer.

Angular Element

All        (206.61 KB)  
main.js    (193.33 KB)  
scripts.js (13.29 KB)  

This includes a Angular project created with ng new, Zone.js import (as it is needed for self contaned elements to work if you don't wan't to use noop zone) and build with ngx-build-plus.

Angular Element + Bootstrap 4 (only min.css)

All        (418.74 KB)  
main.js    (405.46 KB)  
scripts.js (13.29 KB)

This will create quite an amout of overhead. Of course it is possible to share styles between your elements, but this will increase complexity.

---

This leads to the things you can expect if you use Angular Elements

Pro:

• If you compare the official popup service example you will see that you get

  Easy dynamic content in an Angular app

• Native style encapsulation - you now can use encapsulation: ViewEncapsulation.ShadowDom
• (maybe later it will be possible to load different elements that depend on different Angular versions - this is planned but not possible now!)

Contra

• You will get problems with your library approach...
  ... or at least it doesn't integrate well with Angular Elements since:

  ...libraries are intended to be used by Angular apps.

I'm not totally sure if there really is not good approach to use Angular Elements with the library feature, but currently I don't know one. Maybe someone will bring up a good idea here.

• Overall bundle size will increase
  Currently you have to bundle the whole Angular Framework (at least the parts that don't get tree shaken away) into your Angular Element. Again nx-build-plus comes to your rescure and helps sharing dependencies between elements, but this way is not officially supported (but the auhtor of ngx-build-plus is working on an implementation for the Angular team). So you can expect that this point will improve - but not disapear - in comming Angular releases (especially when Ivy will be landing). Depending on how you solve the import problem, other dependencies like Bootstrap will increaes this problem (as shown above).

• If you have to support IE 11
  you will get even more problems with support (and bundle size) as all Web Component (Angular Element) functionality has to be polyfilled.

• Build gets more difficult (at least for now).
  As mentioned above, Angular Elements are not supported in libraries yet and if there is a solution for this, it will need some manual configuration.
  Additionally Angular currently doesn't support "external" Angular Elements (meaning elements outside the Angular Context). Though it is possible to create them manually or with tooling like ngx-build-plus (IMHO the best approach at the moment)

This last point might not be a problem to your team as you mentioned you are only working in an Angular context, but I think it is worth mentioning.

Obedience