some Angular 4 notes on modules learned from an online training

1. It makes sense to loop in FormsModule and ReactiveFormsModule at imports in a wrapper module wrapping an application.
2. import { CommonModule } from '@angular/common'; is a good import for a nested submodule (called a feature module) in contrast to:
   import { BrowserModule } from '@angular/platform-browser'; which is going to be the comparable thing at an outermost module. Both of these make fundamentals like *ngIf and *ngFor possible, but the BrowserModule has some extra mechanics that needs to be at the mouth of an application.
3. When importing a routing module use .forRoot in a wrapping module and .forChild in a nested feature module.
4. You can loop in funtionality at nested modules with a shared module which will be in the imports of both the wrapper/outer module and the nested module(s) where you want to utilize it. In such a shared module, the directive (let's say) to be looped in will be listed at both the declarations and the exports. You may also put CommonModule in the exports so you don't have to explictly loop it in at every nested module that gets the shared module.
5. You may mention components by name in a routing module without them being in imports and without the app breaking. How is this possible? Well, as long as another module loads the component before you visit the component or give a link off to the component, you're gold. It's another thing to call a component by a selector tag however. You'd better be "in scope" for that. (have the component at the immediate module)
6. { path: 'whatever', component: FooComponent } could be refactored as...
   { path: 'whatever', loadChildren: './stuff/bar.module#BarModule' } and assuming there is a BarModule class with an @NgModule decorator in stuff/bar.module.ts and that BarModule is the nested module that manages FooComponent well then this will allow us to lazy load FooComponent.
7. There is a Root Injector that generally hydrates the providers in modules, both app-wide and feature-based. The same logging service instance, for example, should thus be used, as a singleton, in the wrapper God module and a given feature module and you can declare providers for the same service in both places without Angular complaining. When you get into lazy-loaded feature modules well therein it is possible to have a breakout in which a separate instance of the logging module materializes. A shared module across both a regular feature module and a lazy-loaded feature module will behave strangely using the common singleton for the regular feature module and a one off new thing for the lazy-loaded feature module.
8. AuthGuard is one of the few examples of a service you might loop in at providers at a routing module.