Angular: Understanding Modules and Services

…and using them to better organize applications!

Here you are! You are starting to feel comfortable with this framework, and all of the sudden…

Where should I put my services? Am I importing them in the right way? Are my modules well-organized and ready to scale? Is this component in the right place?
How do I even name this folder?

I found that most developers struggle with this questions because they don’t have a clear vision of how Angular Modules work and how important they are for the Dependency Injection mechanism.

In this article we try to lay the foundation for all of your next projects, nothing less! 😃

Feature Modules

In Angular, every module which is not the AppModule is technically a Feature Module, and it has the following caveats:

— It must declare all the components, directives and pipe it needs

We’ll talk about module-scoping soon, but for now it’s important to understand that is not enough to declare a component once in the declarations array of AppModule: in order to use a component in a module, it must be declared in that specific module. The same applies for directives and pipes.

— It must import CommonModule instead of BrowserModule

While BrowserModule must be imported in AppModule (it’s required in order to run the app in the browser), this module must not be imported elsewhere: instead, we must import CommonModule, which contains Angular’s common directives, such as ngIf, ngFor, ngClass, etc… BrowserModule also re-exports CommonModule, so that you can use this directives in AppModule too.

— It doesn’t bootstrap anything

The only module responsible for bootstrapping a component is, obviously, AppModule!

We’ll use Feature Modules to define all of our views, as each view (or scene) will have its own module! And since we’re talking about scenes, we’re also talking about routing. Each “View Module” (let’s call it this way) can be lazy loaded by the router, I already mentioned that in an…