Angular Modules: A Basic Infographic for Who’s Confused
🏁 Intro
Well, this is my first article about Angular and unlike the majority available at the web, this time I’ll try to explain one of its basics concepts in a different way: by pictures and a bit of text.😄For me and most people out there (I believe so), a picture can definitely work better than long texts or bunches of codes especially when we’re dealing with newcomers in some subject.
So, I decided to write this content when I took on my first “real” Angular project at my job — a big and unfinished ERP (Enterprise Resource Planning) web system which was acquired from a third party. I just said: Oh man, brace yourself! I’m really in a pretty pickle. 😐
Actually, I already had some experiences with angular, but nothing relevant, most of them related to little maintenance or changes on pre-existing projects — you can imagine why I got worried. Anyway, since then I shouldn’t be able to perform just a little maintenance, instead I should build entire modules and sections from scratch such that a deep dive into Angular’s land became unavoidable. As we know, Angular itself is a huge framework containing tons of subjects, principles, therms, concepts, patterns and so on. That’s why it can be challenging in fact, coming across with all that it’s not easy for whom is just starting how I was. Many say Angular itself isn’t easy to learn at all especially. I fully agree.
“Angular has a steep learning curve, considering it’s a complete solution, and mastering Angular requires you to learn associated concepts like TypeScript and MVC. Even though it takes time to learn Angular, the investment pays dividends in terms of understanding how the front end works.” From: Angular vs React vs Vue: Which Framework to Choose in 2021.
Although, unexpectedly I had a trick which helped me out over my learning process: My previous experience with Vue and React. I just decided to use them in my favor. At first glance, it could seem weird, but these two guys have some key points in common with Angular, there are still similar concepts among them which can be recycled like “props”, “directives”, “services”, and so forth. However, what I decided to talk about in this text is missing in this team. It’s one of the firsts and fundamentals concepts that you will come across at Angular school: The Modules.
As we will notice over the text, Angular’s architecture is strongly based on a modular concept. Actually, I’d classify the concept of modules itself as “a small world” inside Agular’s land. I got “terrified” the first time I needed to handle them, mixing me up a lot. Let’s take a look at another quote about what I’m trying to emphasize:
“Angular modules is a pretty complex topic. Angular team has done a great job putting up a quite lengthy documentation page on NgModule that can be found here. It provides a clear explanation to most of the topics but some areas are still lacking and thus often misunderstood by developers.” From: Avoiding common confusions with modules in Angular.
Okay, that was purposely used to scare you. Jokes aside, don’t worry, that’s normal for anyone who’s starting on this technology (I swear 😇). Afterward reading a lot, and watching a lot of tutorials, I started putting all that together by making some short notes and reminders regarding what I had learned.
To write this content, I picked up some good references from web and of course, from my postites too.😄 Both briefly quoted over the text, after all, this is aimed to be close to an infographic and not a long and boring text.
⚠️ Who is this article intended for?
As you probably could realize in the intro section, here you’ll find just the basics and summarized concepts about Angular’s modules like definitions and how they work. Nothing further than that. Pictures will be used instead of text or codes actually, you won’t find any code here. Thus, this content is especially aimed at those who are starting on Angular or those who are confused about Angular’s modules concepts, but if you want to, feel free and join us.
Over the text, we are going to keep our attention only on the module’s concept and what it’s tied up, thus before you start it’s recommended to be familiar with other intrinsic Angular concepts like components, services, directives, etc.
Without further ado, let’s get started.
🤔 What a heck is a module?
Straightforward from official Angular team:
“Modules are a great way to organize an application and extend it with capabilities from external libraries. Angular libraries are NgModules, such as FormsModule, HttpClientModule, and RouterModule. Many third-party libraries are available as NgModules such as Material Design, Ionic, and AngularFire2. NgModules consolidate components, directives, and pipes into cohesive blocks of functionality, each focused on a feature area, application business domain, workflow, or common collection of utilities”.
Modules can also add services to the application. Such services might be internally developed, like something you’d develop yourself or come from outside sources, such as the Angular router and HTTP client.
So, we can imagine modules like rooms inside a house where “house” means our whole application. It groups everything related to its own role. Figure 1 shows up a visual concept about what modules are and crucial terms which are wired out on it.
To put it briefly: Use import to get “things” from other modules and make them available in the current one. Use export to provide “things” to other modules. Use declarations to declare all things that will be used only inside the current module. These “things” could be components, pipes, directives, and so on.
For instance, let’s imagine a pretty common scenario where we need to import some components from another module. Figure 2 shows us what happens when module 3 is imported by modules 1 and 2. From this moment, both modules 1 and 2 will be able to access all elements which belong to module 3.
By importing module 3 it will make its inner elements (discussed in the later section) available inside modules 1 and 2. That’s like a merge as shown by Figure 2.
💡 Reminder: Every component needs to be declared inside a module so that we can use it.
🔍What else can dwell inside a module?
Finally, it’s time to demystify what dwells inside a module. I gave some spoilers earlier, referring to all these guys just as “inner elements”. Well, here inner elements could be components, pipes, services, directives as well, or in other words, it’s everything a module can host.
All these inner elements will vary according to the app proposal. There isn’t a rule about that, sometimes a module will have only components, sometimes components and pipes and so on.
Was it easy, wasn’t it? Once we have taken in module main concepts, it’s time to move further…
Taking all that apart
An Angular app can grow quickly with modules coming up everywhere. Without a suitable approach and guidelines, this turns out in a true nightmare as fast as you can imagine. 🤯 Besides, questions like performance, maintenance and security which you willy-nilly are also at stake. To avoid (or at least mitigate) unwanted situations involving these points, Angular’s team classifies modules according to its responsibility so that we can build a solid and reliable architecture for our apps.
In this classification we have some special ones that define the Angular core architecture, those are: App Module, Core Module and Shared Module. So, let’s figure out how all that works starting with the core module.
Figure 4 illustrates the App module (many times called root module) and the Core module alongside its definitions. App module is a very special piece inside every Angular app, where everything starts from and without it, you’d have any Angular app. Pure and simple like that. From the moment you create an Angular app, automatically, either by Angular CLI or from scratch, you must define its entry point, here is where the app module comes into play. Whether you want to or not, an Angular app will ever have at least a module: our dear App module.
App module is the place where all application level components are imported together with other higher level modules which are essential to the building process like BrowserModule, NgModule are also imported inside it. At last, one curiosity about the app module: this module is the only one where the bootstrap keyword comes up — it’s aimed to define the root-component of the application telling Angular where to start. Although, we’ll explore this subject in detail in future posts.
Now, it’s time to talk a bit about the core module concept. This is an especial guy aimed to define common services or top-level components which must be instantiated once (singleton) and can be used by any element in our application.
💡 Core module is only imported once inside the app module as shown in Figure 3*.
For instance, it is a good place to host HTTP services, a Header component or a loading spinner. These are just some possibilities among many others, usually these elements should have only one instance over the app lifecycle.
Now, let’s go on and talk about the shared module… It has the exact opposite meaning as the core module has. This guy is imported in every module that needs to access shared components, pipes, or directives across the structure — common elements. We create that to provide all those common elements at once stead of importing them one by one in every other module. Afterward, we just need to add the shared module to each module and, as a result, it will access all common elements defined by that.
* Angular has its own mechanism to prevent a core module being imported twice. You can find more details about that here.
This idea allows us to organize and streamline our code making it more reusable and readable. In addition, shared modules can reduce the actual size of an application by far, which is extremely relevant mainly when we are working on complex projects.
Without going off this topic, shared modules, there’s an interesting discussion involving importing services.
Usually:
Elements defined inside a shared module may have various instances, in this way it’s recommended to avoid having services in the share module, otherwise you will end up with a lot of instances of them.
But, if you need to:
Angular has a way to provide services from shared modules without making a lot of instances of them by means of a special method named “forRoot” that’s aimed to split out the services from the remaining elements. It works like that: when the shared module is imported by any other feature module, the services defined inside it won’t be reimported again once they were already injected in the root module. As a result, our services still will be singletons as we’d like to.
Unfortunately going further on this subject runs away from our goals, anyhow if you want to get more details, check out this content, it is worthy.
A good way to define which elements will belong to your shared module is choosing those that are used a lot in your application e.g. UI modules like Angular Material.
Indeed, an application can have more than one shared module, so we can refer to it as “shared modules” as well. They can also import other common modules (usually from Angular’s core) that will be provided to our feature modules (discussed in detail in the next section).
Let’s take a look at Figure’s 6 content, where we’ve two shared modules. The first one, labeled as “Shared Module” belongs to the application core, that is, injected directly into the root module and contains all comum elements which should be accessed across the app. Finally, the Audit module in its turn is shared only between “Auth” and “DPO” (Data Protection Officer) modules. That’s cool because we can split and organize what should or not be shared among certain modules after all, why do Audit’s elements should be accessed by any other module whose audit process itself isn’t relevant? In my case, I’m used to following this approach breaking apart modules according to their concerns.
So far we’ve discussed briefly the fundamentals about the basics kinds of Angular’s modules. Now, it’s time to move on covering another great topic: custom modules, also known as feature modules.
Feature modules
As its name implies, feature modules are specialized modules intended to deal with specific features. They will naturally come up as our app grows and we decided to split our code out according to a specific feature, for instance, let’s say a report module that is responsible for generating reports about sales. Notice that this has the opposite meaning of the core module discussed early. For instance, at Figure 5 Auth, DPO and Audit are both feature modules.
For more further details, check this out: Angular Feature Modules.
Types of feature modules
Feature modules can be grouped according to some categories as following:
As Angular’s team mentions, it’s just a suggestion in order to organize and keep correlated code in a modular structure. My tip is: try to use it, believe me, if applied correctly it can make all difference especially in large projects. You can learn more about module categories here: Guidelines for creating NgModules.
Finally, after understanding the official doc, I built the following table that shows up in short the key characteristics of each category. Take it like a pocket guide. 😉
Finishing up
Here, we finish our mini journey through Angular’s modules. This content was just an intro, I’d call it “an unusual intro” where we could check what a module is, their categories, and how they work in fact. Unusual due to the way we made it, straightforward, brief, accessible and, of course, using images to illustrate and abstract tricky concepts (the cherry on the cake).
As mentioned before, modules are a vast subject in Angular’s land that takes some time to get into. This text was just a starting point and I hope you all get more comfortable and encouraged after reading this content. You can go beyond, you should go higher! For that, check out the references described in the section below.
That’s all folks. I hope you all have enjoyed this content. In case of some question or suggestion, please text me. Thank you so much.
References
- General
Google. Guidelines for creating NgModules. Available at: <https://angular.io/guide/module-types> Accessed on November 03, 2020.
Google. NgModules. Available at: <https://angular.io/guide/ngmodules> Accessed on September 20, 2020.
Google. Introduction to modules. Available at: <https://angular.io/guide/architecture-modules> Accessed on September 04, 2020.
PARKER, Chris. Declaring Components in an Angular Module. Available at: <https://www.pluralsight.com/guides/angular-module-declaring-components> Accessed on September 03, 2020.
- Modular architecture
SOSNOWSKI, Damian. Scalable Angular Application Architecture. Available at: <https://bulldogjob.com/articles/539-scalable-angular-application-architecture> Accessed on September 25, 2020.
- Feature modules
AGUAS, João. Angular: Organizing Features and Modules. Available at: <https://medium.com/swlh/angular-organizing-features-and-modules-e582611a720e> Accessed on November 10, 2020.
Coding In Depth. Angular: Why and when to create a feature component and feature module. Available at: <https://medium.com/coding-in-depth/angular-why-and-when-to-create-a-feature-component-and-feature-module-622351b5d136> Accessed on November 11, 2020.
