This article shows how to load Web Components on demand. For this, it demonstrates two approaches: Lazy Loading and loading external components. [Mehr]
Web Components can be reused with each framework and dynamically adding new Web Components to a page is just a matter of creating DOM nodes. In this post, I'm using this idea to build a dynamic dashboard. [Mehr]
Angular depends on zone.js for change detection and in most cases we don't want to force customers of our Web Components into using it. In this short article, I explain how to get rid of zone.js and how to deal with the consequences. [Mehr]
Treeshakable providers come with a new optional API that helps tools like webpack or rollup to get rid of unused services during the build process. Besides smaller bundles, this innovation also allows a more direct and easier way for declaring services.
In this post, I'm showing several options for using this new API and also point to some pitfalls one might run into. [Mehr]
One approach for creating SPA-based clients for microservice environments is loading several Web Components into a page. Using an example, this post shows one way to implement this idea. For this, it leverages Angular Elements which allows to compile Web Components out of Angular projects. [Mehr]
The CLI command ng update allows migrating to a newer version of an installed library. For this, it executes schematics to adopt existing applications to changes. [Mehr]
In my two previous blog posts, I've shown how to leverage Schematics to generate custom code with the Angular CLI as well as to update an existing NgModules with declarations for generated components. The latter one was not that difficult because this is a task the CLI performs too and hence there are already helper functions we can use.
But, as one can imagine, we are not always that lucky and find existing helper functions. In these cases we need to do the heavy lifting by ourselves and this is what this post is about: Showing how to directly modify existing source code in a safe way. [Mehr]
People ask me on regular basis how to use SPAs, esp. Angular-based ones, in a microservice-based environment. The need for such microfrontends is no surprise, as microservices are quite popular nowadays. The underlying idea of microservices is quite simple: Create several tiny applications -- so called microservices -- instead of one big monolytic applications. This leads for instance (but not only) to smaller teams (per microservice) that can make decisions faster and chose for the "best" technology that suites their needs.
But when we want to use several microservices that form a bigger software system in the browser, we need a way to load them side by side and to isolate them from each other so that they cannot interact in an unplanned manner. The fact that each team can use different frameworks in different versions brings additional complexity into play.
Fortunately, there are several approaches for this. Unfortunately, no approach is perfect -- each of them has it's own pros and cons.
To decide for one, a software architect would evaluate those so called architectural candidates against the architectural goals given for the software system in question. Typical (but not the only) goals for SPAs in microservice-based environments are shown in the next section. [Mehr]
Even though the word iframe causes bad feelings for most web devs, it turns out that using them for loading SPAs in a micro service based environment -- aka micro frontends -- is a good choice. For instance, they allow for a perfect isolation between clients and for a separate deployment. Because of the isolation they also allow using different SPA frameworks. Besides iframes, there are other approaches to use SPAs in micro service architectures -- of course, each of them has their own pros and cons. [Mehr]
Since some versions, the Angular CLI uses a library called Schematics to scaffold building blocks like components or services. One of the best things about this is that Schematics allows to create own code generators too. Using this extension mechanism, we can modify the way the CLI generates code. But we can also provide custom collections with code generators and publish them as npm packages. A good example for this is Nrwl's Nx which allows to generated boilerplate code for Ngrx or upgrading an existing application from AngularJS 1.x to Angular.
These code generators are called Schematics and can not only create new files but also modify existing ones. For instance, the CLI uses the latter to register generated components with existing modules.
In this post, I'm showing how to create a collection with a custom Schematic from scratch and how to use it with an Angular project. The sources can be found here. [Mehr]
Although tuning an application's performance can be difficult, sometimes all we need to do is laying back and waiting for the next version of the used framework. This especially holds true for Angular as the Core Team is working constantly on improving things under the hoods. A good example for this is the conciser code the Angular Compiler emits beginning with Version 4 or the Angular Bundle Optimizer that transforms code to make it more treeshakable.
On more of this optimization techniques landed with 5.0.0-beta.4 about two weeks ago. It allows the compiler to remove unneeded (consecutive) white spaces from text nodes and to remove even whole text nodes that only contain white space characters. This leads to less code emitted by the AOT compiler and therefore to smaller bundle sizes as well as faster start up times.
In this post I'm describing how to use it, which performance gains I measured when applying to an example application as well as how this approach works under the covers. The example application I've used for this can be found in my GitHub repository. [Mehr]