👨‍🎨 🧚🏻 👩🏻‍🔬 6 concepts that an Angular application architect needs to master 👃🏼 🙌🏾 🚉

Angular is one of the largest web frameworks in existence. It includes many built-in features. And this means that for the full development of Angular you need to deal with a fair amount of concepts. The author of the material, the translation of which we publish today, believes that there are six concepts that Angular developers need to have in-depth knowledge to create well-designed applications. However, he is not talking about studying the source code for the implementation of these concepts, although he himself sometimes has to look into the code. It is about understanding the relevant mechanisms and the ability to put them into practice.

1. Architecture, modules and libraries

In the web development world, Angular's modular architecture is something special. Probably, this is one of those ideas that are worse than others adopted by beginners.

The hardest part here is that web development already uses a modular architecture. Of course, I'm talking about ES6 imports.

Since Angular-modules add an additional level of logical grouping to the system, it is important that their structure as well as possible corresponds to the tasks solved with their help.

Knowing how to separate and combine application functionality using well-designed modules is a fundamental part of creating an Angular application architecture.

▍Various types of Angular modules

There are various types of Angular modules to be aware of:

Declarations / Widget Module. Modules with declarations of various entities. An example of such modules is the set of user interface components, directives, pipes.
Services Module. Service Modules For example - HttpClientModule.
Routing Module. Routing Modules
Domain Feature Module. Modules that implement the key tasks of the application.
Core / Shared Module. A core module is a module for declaring global services. A shared module is a module in which components are declared for sharing.

Here is the material where you can find details about Angular modules.

▍ Library or module?

I would say that the above distinction between modules can be extended to libraries. With this approach, it turns out that there may be a library containing only services, a library representing the route, and so on.

But whether a module or library is created depends on the type of project, and whether the project is represented by a mono-repository or several repositories.

▍ Questions to ask yourself before creating a module

Here are some questions to ask before writing a module:

? — , . , . , .
, ? . , , . , , .

2. ,

Sharing responsibilities is, in theory, simple. But in practice it is already more difficult. Developers, since the time of Angular.js, knew that components should be made as compact as possible, and services should be made larger. In new versions of Angular, these ideas have not changed much.

And nowadays it is important to have an idea of what exactly should be part of the components, what is part of the services, and also take into account the fact that directives are probably a very underestimated feature of Angular.

▍Condition

The answer to the question of exactly where to store the state of the component depends on where the corresponding data is needed. Namely, they may be needed only in the component, being local and encapsulated, or they may be needed outside the component.

If the components share the state, or the state needs to be accessed from services, then the state should be stored in the service. Moreover, if the state is stored in the service, what particular state management tools are used do not play a special role.
If the state is local (for example, we are talking about the form) and is used only inside the component, then the state should simply be saved in the component.

▍Working with the DOM

Probably most DOM manipulations should be done in directives. Imagine that one of the components is equipped with Drag-and-Drop-functionality.

I am sure that in this situation you can create a component and bind the corresponding events from it, but if you do so, two phenomena will be mixed:

Description of the appearance of the component.
Determination of component behavior.

Directives are an Angular feature that lets you describe reusable mechanisms. In almost every project that I worked on, I noticed the insufficient use of directives. Directives can take a considerable share of the responsibility of components.

Here is an exercise for you: find the largest component in your current project by the number of lines of code. Is it used in it Rendereror ElementRef? Corresponding logic, most likely, can be transferred to the directive.

3. Change detection and rendering

When it comes to re-rendering the user interface, then in Angular everything is done as if by magic, using the internal mechanisms of the framework.

But if you need to optimize the application so that the interface is re-rendered only when it is necessary, you have to deal with this “magic”. And, improving rendering, you have to rely not only on knowledge, but also on intuition.

An Angular application architect should probably be aware that a change detection strategy is used to optimize rendering performance onPush. But in the course of work, everything does not always go as expected. Especially when the templates do not use observable objects and asynchronous pipes.

▍ Improving change detection

In order to improve the change detection process used in the project, it makes sense to start with the following ideas:

It is necessary to consider all data as immutable. Rx-based state management libraries can be very useful here.
To output data in templates, it is worth using only (or mainly) observable objects. When using a local state, it is worth applying BehaviorSubject.

If you want to develop high-performance Angular applications, you just need to deal very well with change detection issues. The fact is that high performance is not even “updating the interface when it is needed”. This is “updating the interface only when it is needed.”

▍ Overcoming Angular Performance Limitations

Reducing the number of re-renderings of the application interface is one of the secrets that allows you to create fast and efficient applications. But sometimes application performance must go beyond the boundaries defined by the Angular device itself. Among such applications can be noted games, projects whose data is often updated, pages that display large and complex lists, and so on.

If you really need to squeeze the absolute maximum out of Angular performance, this means that you should resort to a technique that involves getting rid of Zone.js and accurately updating the interface using the latest Ivy features. Here is the material about it.

4. Routing

Routing is not only a representation of SPA in the form of many virtual pages. It is also loading application bundles on demand using the lazy loading capabilities of Angular routing subsystem materials.

If you are working on a large application and the bundle size of this application exceeds 1 MB, then you probably already know why this is important. Indeed, no one will find the prospect of downloading huge amounts of data to work with a certain application.

Routing should be used not only to separate top-level routes, but also to organize work with the shallower and deeper parts of the interface.

This allows you to split the contents of bundles by main routes and helps to divide applications into small parts that do not need to be transferred to users until an explicit request is made to download them.

▍ Example: tabbed component

Suppose we are developing a user interface that uses tabs. Moreover, each tab is independent of the others. This is an ideal situation in which each tab can be assigned its own route and organize lazy data loading, during which only the data of the selected tab is transmitted to the client.

Want another example? What about pop-ups and modal windows? Their code absolutely does not need to be included in the materials included in the original bundle of the project. The code of such windows makes sense to load only when they are needed, but not earlier.

If you want something inspired before applying such ideas, I suggest taking a look at the documentation of the @ angular / material / tabs component , which implements the above pattern.

5. Forms

Most CRUD applications are essentially made up of many forms. It is very likely that you spend a lot of time creating forms. Therefore, it is important for someone who wants to be an Angular architect to master working with forms properly.

Most of your forms are likely to use a module ReactiveFormsModule. And if they do not consist of a single control, then using them, ngModeltwo-way data binding will be implemented.

The Angular API for working with forms is pretty easy to learn. In order to achieve excellence in the use of this API, in general, it is enough to study the documentation properly and know what problems may arise when working with forms.

The main problem worth knowing is that the forms in Angular are not bound to the data types that underlie them. This is probably the most unpleasant thing about working with mechanisms that are otherwise very well made. As a result, it turns out that the developer needs to carefully monitor that the forms correspond to the data structures that are used when working with them.

6. RxJS

And the last on our list, although not the least, is RxJS technology.

I am convinced that one of the most powerful features of Angular is the deep integration of this framework with Rx and functional reactive programming.

In order to truly master Angular, paving the way for the design of high-quality applications, you first need to study Rx, or at least the most important operators. It's hard to be a truly advanced Angular developer without spending a lot of hours understanding Rx.

There are two reasons for learning Rx to help you develop Angular applications: performance and asynchronous data processing.

Asynchronous data processing is a particularly difficult task in modern, highly interactive applications. Therefore, you should forget about promises, oh setTimeoutand oh setInterval, and start working in the Rx style.

Another serious reason to learn Rx is to optimize application performance. Of course, to start with, it is enough to use asynchronous pipes, but sometimes this is not enough. For example, you can control the re-rendering of components by passing only those events through the pipe, the occurrence of which implies the need for re-rendering.

Rx provides the developer with many operators that can help him cache something, or build something into packages. And this, as a result, leads to optimized application performance. Here material about the RxJS patterns.

Summary

I have given here a short list of topics that are worth exploring for someone who wants to become a high-performance Angular developer, or someone who wants to be an Angular application architect.

You can add a lot more to this list. But, among other things, I propose not to forget that in order to really learn something about the world of web development, you need to start with the basics. These are JavaScript, CSS, design patterns, clean code writing techniques, tools, and much more.

And what would you advise to study for those who want to learn how to design high-quality Angular-applications?

6 concepts that an Angular application architect needs to master