This tutorial will seek to answer most of the frequently asked questions about NgModules.
What classes should I add to the declarations array?
Add declarable classes-components, directives, and pipes-to a declarations list.
Declare these classes in exactly one module of the application. Declare them in a module if they belong to that particular module.
What is declarable?
Declarables are the class types—components, directives, and pipes—that you can add to a module's declarations list. They're the only classes that you can add to declarations.
What classes should I not add to declarations?
Add only declarable classes to an NgModule's declarations list.
Do not declare the following:
- A class that's already declared in another module, whether an app module, @NgModule, or third-party module.
- An array of directives imported from another module. For example, don't declare FORMS_DIRECTIVES from @angular/forms because the FormsModule already declares it.
- Module classes.
- Service classes.
- Non-Angular classes and objects, such as strings, numbers, functions, entity models, configurations, business logic, and helper classes.
Why list the same component in multiple NgModule properties?
AppComponent is often listed in both declarations and bootstrap. You might see the same component listed in declarations, exports, and entryComponents.
While that seems redundant, these properties have different functions. Membership in one list doesn't imply membership in another list.
AppComponent could be declared in this module but not bootstrapped.
AppComponent could be bootstrapped in this module but declared in a different feature module.
A component could be imported from another app module (so you can't declare it) and re-exported by this module.
A component could be exported for inclusion in an external component's template as well as dynamically loaded in a pop-up dialog.
What does "Can't bind to 'x' since it isn't a known property of 'y'" mean?
This error often means that you haven't declared the directive "x" or haven't imported the NgModule to which "x" belongs.
What should I import?
Import NgModules whose public (exported) declarable classes you need to reference in this module's component templates.
This always means importing CommonModule from @angular/common for access to the Angular directives such as NgIf and NgFor. You can import it directly or from another NgModule that re-exports it.
Import FormsModule from @angular/forms if your components have [(ngModel)] two-way binding expressions.
Import shared and feature modules when this module's components incorporate their components, directives, and pipes.
Import BrowserModule only in the root AppModule.
Should I import BrowserModule or CommonModule?
The root application module, AppModule, of almost every browser application should import BrowserModule from @angular/platform-browser.
BrowserModule provides services that are essential to launch and run a browser app.
BrowserModule also re-exports CommonModule from @angular/common, which means that components in the AppModule module also have access to the Angular directives every app needs, such as NgIf and NgFor.
Do not import BrowserModule in any other module. Feature modules and lazy-loaded modules should import CommonModule instead. They need the common directives. They don't need to re-install the app-wide providers.
Importing CommonModule also frees feature modules for use on any target platform, not just browsers.
What should I export?
Export declarable classes that components in other NgModules are able to reference in their templates. These are your public classes. If you don't export a declarable class, it stays private, visible only to other components declared in this NgModule.
You can export any declarable class—components, directives, and pipes—whether it's declared in this NgModule or in an imported NgModule.
You can re-export entire imported NgModules, which effectively re-exports all of their exported classes. An NgModule can even export a module that it doesn't import.
What should I not export?
Don't export the following:
- Private components, directives, and pipes that you need only within components declared in this NgModule. If you don't want another NgModule to see it, don't export it.
- Non-declarable objects such as services, functions, configurations, and entity models.
- Components that are only loaded dynamically by the router or by bootstrapping. Such entry components can never be selected in another component's template. While there's no harm in exporting them, there's also no benefit.
- Pure service modules that don't have public (exported) declarations. For example, there's no point in re-exporting HttpClientModule because it doesn't export anything. Its only purpose is to add http service providers to the application as a whole.
- Weekly Trends
- Python Interview Questions and Answers: Comprehensive Guide
- Scala Exercises, Practice, Solution
- Kotlin Exercises practice with solution
- MongoDB Exercises, Practice, Solution
- SQL Exercises, Practice, Solution - JOINS
- Java Basic Programming Exercises
- SQL Subqueries
- Adventureworks Database Exercises
- C# Sharp Basic Exercises
- SQL COUNT() with distinct
- Java Collection Exercises
- SQL COUNT() function
- SQL Inner Join