You have unlimited access as a PRO member
You are receiving a free preview of 3 lessons
Your free preview as expired - please upgrade to PRO
- Object Oriented Programming With TypeScript
- Angular Elements Advanced Techniques
- TypeScript - the Basics
- Cloud Scheduler for Firebase Functions
- Testing Firestore Security Rules With the Emulator
- How to Use Git and Github
- Infinite Virtual Scroll With the Angular CDK
- Build a Group Chat With Firestore
- Async Await Pro Tips
A Simple Explanation of NgModuleEpisode 22 written by Jeff Delaney
I wrote this post for those who don’t want to spend all day reading the entire NgModule FAQ.
Angular apps are built with on complex relationship of view classes (i.e. components, directives, and pipes) and data providers (i.e. services). In the early days of Angular2, NgModule did not exist and you had to declare every relationship in every component. It was maintenance nightmare.
NgModule was introduced later down to road to solve this problem by allowing you to declare all the relationships at in one fell swoop with metadata. When you add Angular CLI to the mix, much of this work is done automatically with the command line.
Angular talks about imperative and declarative components… What’s the difference?
- Declarative components are the ones in the HTML, i.e
- Imperative components never get used in the HTML. They are loaded by the router, or bootstrapped.
That settles that
An NgModule is collection of metadata describing components, directives, services, pipes, etc. When you add these resources to the NgModule metadata, Angular creates a component factory, which is just an Angular class that churns out components.
NgModules are built with metadata. Let’s look at each of the main types below. (Note: views refers to components, directives, and pipes)
- declarations - Declare views to make them privately available in this module.
- exports - Makes the declared view public so they can be used by other modules.
- imports - This is where you import other modules.
- providers - Defines services that can be injected into this module’s views.
- bootstrap - The component used to launch the app, the
AppComponentby default. All apps must have at least one.
Multiple NgModules provides two potential benefits.
- It keeps business logic organized. Try putting 100 resources in the default app module and see what happens.
- It opens the possibility for lazy loading via the router.
You can create an NgModule by running:
ng generate module <module_name>
Once created, you can automatically add resources to the module by running:
ng generate component <comp_name> --module <module_name>
This command will create a new component, then add it to the declarations of the module you specified.
- Features - Related business logic that can be packaged into a single concern.
- Routing - Used to manage routes. Should not declare anything.
- Service - Modules that only contain services/providers.
- Widget/Shared- Components you use everywhere. Loading spinners, social media icons, etc.
Common design pattern for NgModule
It depends on developer preference, but if your app has more than 3 to 5 closely related components, it’s probably time to refactor - especially if you expect this more related components in the future. The sooner you refactor into a module the better, as it will only get harder as the complexity grows.
That’s it for
NgModule. Let me know what you think in the comments.