Creating shared modules allows you to organize and streamline your code. You can put commonly\nused directives, pipes, and components into one module and then import just that module wherever\nyou need it in other parts of your app.
\nConsider the following module from an imaginary app:
\nNote the following:
\nCommonModule because the module's component needs common directives.CommonModule and FormsModule.By re-exporting CommonModule and FormsModule, any other module that imports this\nSharedModule, gets access to directives like NgIf and NgFor from CommonModule\nand can bind to component properties with [(ngModel)], a directive in the FormsModule.
Even though the components declared by SharedModule might not bind\nwith [(ngModel)] and there may be no need for SharedModule\nto import FormsModule, SharedModule can still export\nFormsModule without listing it among its imports. This\nway, you can give other modules access to FormsModule without\nhaving to import it directly into the @NgModule decorator.
There is an important distinction between using another module's component and\nusing a service from another module. Import modules when you want to use\ndirectives, pipes, and components. Importing a module with services means that you will have a new instance of that service, which typically is not what you need (typically one wants to reuse an existing service). Use module imports to control service instantiation.
\nThe most common way to get a hold of shared services is through Angular\ndependency injection, rather than through the module system (importing a module will result in a new service instance, which is not a typical usage).
\nTo read about sharing services, see Providers.
\nYou may also be interested in the following:
\n\n\n \n