关于Angular NgModules的疑问：子模块创建及相关问题咨询

Hey Kevin, totally get where you're coming from—NgModules can feel like a confusing layer even after digging through docs and tutorials. Let's unpack your questions, plus clarify that note about services you mentioned first.

First, quick note on services: You're right! Starting in Angular v6, if you define a service with providedIn: 'root' (like below), you don't need to add it to any module's providers array. This enables tree-shaking (so unused services get removed from your build) and ensures the service is a singleton by default.

@Injectable({
  providedIn: 'root'
})
export class AuthService {}

Now onto your core questions:

1. Why create sub-NgModules like auth.module.ts? #

Sub-modules are all about organizing and scaling your app. Here are the key reasons:

• Functional grouping: They let you bundle all code related to a single feature (like authentication) into one place—components, services, routes, pipes, and directives all live together, making it easy to track and modify that feature's logic.
• Encapsulation: You can hide internal implementation details of the module. Only the components/directives/pipes you add to the module's exports array are accessible to other parts of the app, preventing naming collisions and reducing unintended dependencies.
• Reusability: If you need authentication logic in another project or a different part of this app, you can just import the AuthModule instead of copying code.
• Lazy loading: Sub-modules can be loaded on demand (when the user navigates to a related route) instead of being included in the initial app bundle. This drastically improves initial load times for larger apps.

2. What advantages do they have over using only app.module.ts? #

Sticking everything in AppModule works for tiny apps, but as your project grows, it becomes unmanageable. Here's why sub-modules are better:

• Cleaner code organization: AppModule won't turn into a massive, cluttered file with hundreds of declarations and imports. Each sub-module focuses on one feature, so you can find and maintain code faster.
• Performance boosts: Lazy loading sub-modules cuts down your initial bundle size, meaning users see your app faster.
• Better team collaboration: Multiple developers can work on different sub-modules (e.g., one on auth, another on user profiles) without constantly conflicting on the same AppModule file.
• Single-responsibility principle: Each module handles one specific domain, making your code more robust and easier to test.

3. Do I need to import sub-NgModules into app.module.ts? #

It depends on how you're using the sub-module:

• Eager-loaded modules: If the module's functionality is needed immediately when the app starts (like a shared module with common components), yes—add it to AppModule's imports array.
• Lazy-loaded modules: No! These are loaded dynamically via routing (using loadChildren in your route config), so you shouldn't add them to AppModule's imports. Doing so would negate the lazy loading benefit.
• Shared modules: If you have a module with reusable components (like a ButtonComponent), you'll need to import it into every feature module that uses those components—not just AppModule.

4. What else should I know about NgModules? #

Here are some critical details that often get overlooked:

• Module types:
  • Root Module (AppModule): Every app has exactly one—this is where you bootstrap your root component and configure app-wide settings.
  • Feature Modules: The AuthModule example you mentioned—focused on a specific feature.
  • Shared Modules: Store reusable UI components, pipes, and directives (e.g., SharedModule with a DatePipe or SpinnerComponent). Be sure to export these items so other modules can use them.
  • Core Modules: Hold global singleton services (like a LoggerService or AuthService) that only need one instance. Import this once in AppModule and don't export it to avoid accidental reimports.
• exports array: This is how you expose parts of your module to others. If you want a component from AuthModule to be used in AppComponent, add that component to AuthModule's exports array, then import AuthModule into AppModule.
• forRoot()/forChild() pattern: For modules with routing (like AuthModule), use forRoot() when importing into AppModule to set up root-level routes, and forChild() when importing into other feature modules for child routes. This prevents duplicate instances of routing services.
• Injector scoping: By default, services with providedIn: 'root' live in the root injector (singleton). If you add a service to a sub-module's providers array, each module that imports it gets a new instance—use this only if you need non-singleton services.

内容的提问来源于stack exchange，提问作者KevinTale