Exploring the Module Varieties in Angular

This discussion focuses on the various module categories that can exist within an Angular application. If you're new to Angular Modules, reviewing this introductory article would be beneficial. Additionally, familiarity with creating custom modules is assumed; the process is outlined in this guide.

📣 Note
This is largely a conceptual piece aimed at clarifying the role of each module type. At this stage, they might seem like isolated ideas. Forthcoming articles will walk through each type with concrete examples, showing how these pieces connect.


Let's first consider why multiple module types are necessary. (One type has already been touched upon in the previous post).
As your application expands, division into logical sections becomes essential for-

maintainability,
enhance the performance,
scalability,
easy deployment,
enhance the development process.

To accomplish these objectives, module is a crucial tool.

An application may contain six (6) distinct module types (based on requirements; not all six are mandatory).

1️⃣ Root Module (🔴 Mandatory 🔴)
2️⃣ Feature Module (🟡 Optional 🟡)
3️⃣ Routing Module ( 🟡 Optional 🟡)
4️⃣ Service Module (🟡 Optional 🟡)
5️⃣ Widget Module (🟡 Optional 🟡)
6️⃣ Shared Module (🟡 Optional 🟡)

1️⃣ Root Module
You've likely encountered this one already.
When starting a new Angular project, you receive a module named app.module.ts. Recall that?
This acts as the root module; consider it the parent that all other modules end up nested under, directly or indirectly.
An application permits only one root module.

2️⃣ Feature Module
For extensive applications (think of an eCommerce site like Amazon) that handle numerous distinct areas, breaking the app down by these areas (e.g., users, products, payments) is necessary.
Each grouping is encapsuled in a Feature module.
Think of it like a top-level 'Entertainment' folder holding subfolders like 'Music', 'Movies', 'Games', and 'Photos'. Those subfolders mirror feature modules—all related components live together.

3️⃣ Routing Module
When an app supports navigation (more than a single view), a routing module becomes necessary. In such situations, the Routing module is required.
More details on routing modules can be found in this resource.

4️⃣ Service Module - (comprehensive details coming shortly)
These modules consist solely of services, which might include utility services.
The service module should only reside within the root module.
This concept will become clearer once we discuss services in depth.

5️⃣ Widget Module
A widget module refers to a third-party UI component library that exposes components/ pipes/ directives through its export array.
Suppose you create a table component and want other teams inside your org to use it. The module housing that table component is indeed a widget module.
Those teams import your module to leverage the table in their code.

6️⃣ Shared Module
Components, directives, and pipes that multiple modules in your app use repeatedly belong in a special shared module.
If you have a table component used across various screens and modules within your application, the Shared Module is the vehicle for that reuse.


I hope you found this write-up informative (it's theoretical, but this groundwork will prove valuable later. Take my word for it).

Enjoyed this? Please consider liking, sharing, and commenting.

Next topic: Communication between components.
Keep an eye out.

I'll be posting more on Angular JavaScript TypeScript CSS over on Twitter
Look forward to seeing you over there 😃

Cheers!!!
Happy Coding