Exciting news from this year’s NG Poland!
Monday the 24th of October seemed a day just like any other. I stepped into a modern-looking building in the wonderful city of Warsaw and didn’t know this might change my life forever! :o Well, not really about the forever part, but it was a step outside my regular day-to-day development work.
This year Angular turns 6, and it has not been standing still! I’ll try to put in a few lines about what I feel could improve your daily project experience.
NX seems to become the norm
Modern Angular applications seem to be increasingly organized in monorepos. That means all code can live together in the same project (backend, frontend & other libraries). Individual apps can still be deployed and developed individually and even released separately. NX facilitates this by enhancing the ‘ ‘ CLI’s capabilities and suggesting a code structure. The good people at NX have top-notch experience working at Big Tech like Facebook (Meta) or Google. NX is now used by 50% of the Fortune 500 companies in key projects and has over 1.5 million users, so it’s no wonder it’s becoming the norm.
DDD is not some weird abbreviation for the Backend people
There is a way to design your frontend app’s structure using clean architecture principles. Manfred Steyer talked about arranging your components in hierarchically structured libraries with one-way accessibility directions. That is, all feature libraries can only access the Shared library horizontally while accessing only lower-tiered libraries within the same library vertically.
The feature block contains what we usually call smart components, while the lower-tiered libraries contain dumber components. The API block in the image can be abstracted to something like a Data Access that takes care of things like HTTP, Web Sockets, reading files, etc.
There is a cool plugin for NX called @angular-architects/ddd that can be used to initialize and generate domain, feature, models, data services, etc., while also adding required linting rules for access restrictions between architectural units, as described later on.
What even is Module Federation? 🤔
Apparently, people are doing micro-frontends nowadays. We ‘don’t do that in our project (yet!), but I think it’s a very interesting concept that offers great flexibility. Multiple teams can work on different features (areas of responsibility), and the nice people at https://www.angulararchitects.io/ have created a package that can help generate apps that run on different ports within the same NX monorepo :o! This separation is done seamlessly for the end-user that will not know about (and probably ‘won’t want to invest in) some fancy tech that allows better separation of concerns.
NX allows the creation of shared libs easily, which can be accessed from apps even if they run in different bubbles. So, I guess module federation allows loading separately compiled and deployed code into a single seamless app.
Use linter to enforce architecture
It was great to see that ESLint-defined rules can be used to ensure everyone is adhering to the established architecture. NX defines @nrwl/nx/nx-enforce-module-boundaries that can be configured to ensure illegal imports between libraries are not allowed. Tools like IntelliJ/WebStorm can use these violations to show you what ‘ ‘you’re doing wrong as you type. It can also be used to gate checked-in code so we can catch architectural issues early.
Cool new standalone components
Angular is slowly moving away from the ngModules tech. And it makes sense! JavaScript already provides a good enough module structure. Other modern frameworks like React and Vue also allow the creation of components that are not part of a custom framework module.
Angular 14 allows the creation of standalone components and using a file like index.ts you can create a barrel that truly encapsulates what you want to keep secret from what you want to be accessible from the outside. This can be used to give pretty names to your code packages by specifying this in the tsconfig.json file.
So instead of doing the annoying ../../../.. … pattern when importing code, you can do coolish things like:
ngModules were initially introduced to provide a compilation context that ViewEngine could use to learn where to find different components. With the advent of the Ivy compiler, this is no longer necessary, and every component has its compilation context.
Separation of concerns doesn’t mean separation of files
SFCs are also a thing! SFC stands for Single File Component. And now that Angular allows the creation of standalone components, you can create your entire component in a single file, together with the template and styling. Modern tools (like WebStorm) offer the functionality to navigate to code, assist code completion, etc., for templates, even if they’re defined in the template property of a component.
A shiny and (not-so-) new inject() function
Angular 14 updated a function to a new and improved version. That function is inject() and can be used almost everywhere. It can be used especially to reduce the dependencies on constructor methods and reduce the need for them. ‘ ‘I’m not a fan of inheritance in the Angular world, but it can also mean that inheriting will reduce the need to pass those tokens to the super(…) call. Now inject() can offer some inferred type detection which is helpful.
Typed forms and NGRX component-store
There was a cool example of using an NGRX component store together with a component that consists of a strongly typed form. Yes! The #1 request in the Angular backlog has finally arrived. Your old forms looked something like this:
…will now be automagically migrated to UntypedFormControl fields. You can also have specified types as in new FormControl<string | null>(null).
‘ ‘There’s more to it than that, but to cut a long story short, the coding practice consisted of combining a cool new form like that with the awesome component-store library provided by the NGRX team. This library can be loaded separately so that you can choose not to get the NGRX store shenanigans if you so desire. The component-store API can be used instead of the service-with-a-subject approach to confer an alternative that is more Redux-like. More awesome things about it can be seen at https://ngrx.io/guide/component-store.
New incoming Google things for Angular
Some folk at Google gave us a little bit of a sneak peek at what ‘ ‘they’re working on next. Some of the improvements will allow better scores in performance tests like Lighthouse, which is a direct result of the Aurora project. Since Chrome and Angular are under the same roof, ‘ ‘they’ve been able to work together to improve the developer experience in several aspects. One of the incoming things is better to stack traces in the browsers when investigating Angular issues. Many of the items from the stack that were cryptic and unreadable (zone.js stack traces, ‘ ‘I’m looking at you) have been cleaned up to make debugging more relevant and helpful.
In Angular 14, we are receiving ngOptimizedImage. This will allow improvements of LCP (Largest Contentful Paint) images, marking some as lazy loaded and helping select the most relevant picture size for the device the app is running on.
Alex Rickabaugh talked about looking at current strategies for hydration. Angular currently uses something called destructive hydration, meaning that when the server finishes rendering and provides the HTML to the browser, the client-side logic needs to take over. Destructive hydration means that the client-side scripts will destroy the DOM and re-rendering it based on what it received. Non-destructive hydration will allow the re-rendering of only what changed by attaching event listeners and building internal structures. That is not exactly a very new discussion (https://github.com/angular/angular/issues/13446), but it’s something that Ivy opened up.
I would say that there’s a lot to process there, and this was only a partial report from ng-Conf. I love these types of events as there are a lot of cool things to learn about in the tech I’m interested in. Angular seems to be in no danger of ever slowing down its pace, and the innovations coming to it certainly got me excited.
About me
My name is Alexandru Macavei, and I’m a Senior Systems Engineer working for Systematic, mainly with Library & Learning applications. I focus on Angular & frontend, but my day-to-day job involves interactions with various other technologies. I’m happy to talk about code with my work buddies, and I find a lot of benefits in teamwork as a means to deliver software products.
