@@ -28,30 +28,31 @@ There are two main kinds of entry components:
The following is an example of specifying a bootstrapped component,
`AppComponent`, in a basic `app.module.ts`:
-```javascript
+```typescript
@NgModule({
- declarations: [
- AppComponent
- ],
- imports: [
- BrowserModule,
- FormsModule,
- HttpModule,
- AppRoutingModule
- ],
- providers: [],
- bootstrap: [AppComponent] // bootstrapped entry component
+ declarations: [
+ AppComponent
+ ],
+ imports: [
+ BrowserModule,
+ FormsModule,
+ HttpModule,
+ AppRoutingModule
+ ],
+ providers: [],
+ bootstrap: [AppComponent] // bootstrapped entry component
})
```
+
A bootstrapped component is an entry component
-that Angular loads into the DOM during the bootstrap (application launch), process.
+that Angular loads into the DOM during the bootstrap process (application launch).
Other entry components are loaded dynamically by other means, such as with the router.
Angular loads a root `AppComponent` dynamically because it's listed by type in `@NgModule.bootstrap`.
-A component can also be bootstrapped imperatively with the module's `ngDoBootstrap()` method.
+A component can also be bootstrapped imperatively in the module's `ngDoBootstrap()` method.
The `@NgModule.bootstrap` property tells the compiler that this is an entry component and
it should generate code to bootstrap the application with this component.
@@ -66,18 +67,18 @@ A bootstrapped component is necessarily an entry component because bootstrapping
The second kind of entry component occurs in a route definition like
this:
-```javascript
+```typescript
const routes: Routes = [
- {
- path: '',
- component: CustomerListComponent
- }
+ {
+ path: '',
+ component: CustomerListComponent
+ }
];
```
A route definition refers to a component by its type with `component: CustomerListComponent`.
-All router components must be `entryComponents`. Because this would require you to add the component in two places (router and `entryComponent`) the Compiler is smart enough to recognize that this is a router definition and automatically add the router component into `entryComponents`.
+All router components must be entry components. Because this would require you to add the component in two places (router and `entryComponents`) the Compiler is smart enough to recognize that this is a router definition and automatically add the router component into `entryComponents`.
## The `entryComponents` array
@@ -93,11 +94,11 @@ The code should contain only the classes that you actually need and
exclude components that are never used. For this reason, the Angular compiler only generates code for components which are reachable from the `entryComponents`; This means that adding more references to `@NgModule.declarations` does not imply that they will necessarily be included in the final bundle.
In fact, many libraries declare and export components you'll never use.
-For example, a material design library will export all components because it doesn’t know which ones the you will use. However, it is unlikely that the you will use them all.
+For example, a material design library will export all components because it doesn’t know which ones you will use. However, it is unlikely that you will use them all.
For the ones you don't reference, the tree shaker drops these components from the final code package.
If a component isn't an _entry component_ or isn't found in a template,
-The tree shaker will throw it away. So, it's best to add only the components that are truly entry components to help keep your app
+the tree shaker will throw it away. So, it's best to add only the components that are truly entry components to help keep your app
as trim as possible.
@@ -110,7 +111,3 @@ You may also be interested in the following:
* [Lazy Loading Modules with the Angular Router](guide/lazy-loading-ngmodules).
* [Providers](guide/providers).
* [NgModules FAQ](guide/ngmodule-faq).
-
-
-
-
diff --git a/aio/content/guide/feature-modules.md b/aio/content/guide/feature-modules.md
index e29cfa6c0b..97d4e7fa51 100644
--- a/aio/content/guide/feature-modules.md
+++ b/aio/content/guide/feature-modules.md
@@ -36,7 +36,7 @@ pipes that it shares.
Assuming you already have a CLI generated app, create a feature
module using the CLI by entering the following command in the
root project directory. Replace `CustomerDashboard` with the
-name of your module. You can omit the word module because the CLI appends it:
+name of your module. You can omit the "Module" suffix from the name because the CLI appends it:
```sh
ng generate module CustomerDashboard
@@ -46,21 +46,17 @@ ng generate module CustomerDashboard
This causes the CLI to create a folder called `customer-dashboard` with a file inside called `customer-dashboard.module.ts` with the following contents:
-```ts
-
+```typescript
import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
@NgModule({
- imports: [
- CommonModule
- ],
- declarations: []
+ imports: [
+ CommonModule
+ ],
+ declarations: []
})
-
export class CustomerDashboardModule { }
-
-
```
The structure of an NgModule is the same whether it is a root module or a feature module. In the CLI generated feature module, there are two JavaScript import statements at the top of the file: the first imports `NgModule`, which, like the root module, lets you use the `@NgModule` decorator; the second imports `CommonModule`, which contributes many common directives such as `ngIf` and `ngFor`. Feature modules import `CommonModule` instead of `BrowserModule`, which is only imported once in the root module. `CommonModule` only contains information for common directives such as `ngIf` and `ngFor` which are needed in most templates, whereas `BrowserModule` configures the Angular app for the browser which needs to be done only once.
@@ -76,7 +72,7 @@ ng generate component customer-dashboard/CustomerDashboard
This generates a folder for the new component within the customer-dashboard folder and updates the feature module with the `CustomerDashboardComponent` info:
-
+
@@ -85,7 +81,7 @@ The `CustomerDashboardComponent` is now in the JavaScript import list at the top
## Importing a feature module
-To incorporate the feature module into your app, you have to let the root module, `app.module.ts`, know about it. Notice the `CustomerDashboardModule` export at the bottom of `customer-dashboard.module.ts`. This exposes it so that other modules can get to it. To import it into the AppModule, add it to the imports in `app.module.ts` and to the imports array:
+To incorporate the feature module into your app, you have to let the root module, `app.module.ts`, know about it. Notice the `CustomerDashboardModule` export at the bottom of `customer-dashboard.module.ts`. This exposes it so that other modules can get to it. To import it into the `AppModule`, add it to the imports in `app.module.ts` and to the `imports` array:
@@ -104,7 +100,7 @@ When the CLI generated the `CustomerDashboardComponent` for the feature module,
To see this HTML in the `AppComponent`, you first have to export the `CustomerDashboardComponent` in the `CustomerDashboardModule`. In `customer-dashboard.module.ts`, just beneath the declarations array, add an exports array containing `CustomerDashboardModule`:
-
+
@@ -129,6 +125,4 @@ Now, in addition to the title that renders by default, the `CustomerDashboardCom
You may also be interested in the following:
* [Lazy Loading Modules with the Angular Router](guide/lazy-loading-ngmodules).
* [Providers](guide/providers).
-* [Types of NgModules](guide/module-types).
-
-
+* [Types of Feature Modules](guide/module-types).
diff --git a/aio/content/guide/frequent-ngmodules.md b/aio/content/guide/frequent-ngmodules.md
index e50bf17bcb..acd8a633b4 100644
--- a/aio/content/guide/frequent-ngmodules.md
+++ b/aio/content/guide/frequent-ngmodules.md
@@ -55,13 +55,13 @@ of some of the things they contain:
RouterModule |
- @angular/forms |
+ @angular/router |
For Routing and when you want to use RouterLink,.forRoot(), and .forChild() |
- HttpModule |
- @angular/http |
+ HttpClientModule |
+ @angular/common/http |
When you to talk to a server |
@@ -73,29 +73,25 @@ When you use these Angular modules, import them in `AppModule`,
or your feature module as appropriate, and list them in the `@NgModule`
`imports` array. For example, in the basic app generated by the CLI,
`BrowserModule` is the first import at the top of the `AppModule`,
-`app.module.ts`. Notice that this is the same case for `FormsModule` and `HttpModule`.
+`app.module.ts`.
-```javascript
+```typescript
/* import modules so that AppModule can access them */
import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
-import { FormsModule } from '@angular/forms';
-import { HttpModule } from '@angular/http';
import { AppComponent } from './app.component';
@NgModule({
-declarations: [
- AppComponent
-],
-imports: [ /* add modules here so Angular knows to use them */
- BrowserModule,
- FormsModule,
- HttpModule
-],
-providers: [],
-bootstrap: [AppComponent]
+ declarations: [
+ AppComponent
+ ],
+ imports: [ /* add modules here so Angular knows to use them */
+ BrowserModule,
+ ],
+ providers: [],
+ bootstrap: [AppComponent]
})
export class AppModule { }
```
@@ -135,4 +131,3 @@ You may also be interested in the following:
* [Bootstrapping](guide/bootstrapping).
* [NgModules](guide/ngmodules).
* [JavaScript Modules vs. NgModules](guide/ngmodule-vs-jsmodule).
-
diff --git a/aio/content/guide/lazy-loading-ngmodules.md b/aio/content/guide/lazy-loading-ngmodules.md
index e38dbbfca9..48265a9a2c 100644
--- a/aio/content/guide/lazy-loading-ngmodules.md
+++ b/aio/content/guide/lazy-loading-ngmodules.md
@@ -5,10 +5,11 @@ A basic understanding of the following:
* [Feature Modules](guide/feature-modules).
* [JavaScript Modules vs. NgModules](guide/ngmodule-vs-jsmodule).
* [Frequently Used Modules](guide/frequent-ngmodules).
-* [Types of Modules](guide/module-types).
+* [Types of Feature Modules](guide/module-types).
* [Routing and Navigation](guide/router).
-For the final sample app with two lazy loaded modules that this page describes, see the .
+For the final sample app with two lazy loaded modules that this page describes, see the
+.
@@ -33,7 +34,7 @@ ng new customer-app --routing
This creates an app called `customer-app` and the `--routing` flag
generates a file called `app-routing.module.ts`, which is one of
-the files you need for setting up lazy loading for your feature module.
+the files you need for setting up lazy loading for your feature module.
Navigate into the project by issuing the command `cd customer-app`.
## Create a feature module with routing
@@ -64,7 +65,7 @@ ng generate component customers/customer-list
```
This creates a folder inside of `customers` called `customer-list`
-with the four files that make up the component.
+with the four files that make up the component.
@@ -92,8 +93,8 @@ ng generate component orders/order-list
## Set up the UI
Though you can type the URL into the address bar, a nav
-is easier for the user and more common. Replace the default
-placeholder markup in `app.component.html` with a custom nav
+is easier for the user and more common. Replace the default
+placeholder markup in `app.component.html` with a custom nav
so you can easily navigate to your modules in the browser:
@@ -224,7 +225,4 @@ knows that the route list is only responsible for providing additional routes an
You may also be interested in the following:
* [Routing and Navigation](guide/router).
* [Providers](guide/providers).
-* [Types of NgModules](guide/module-types).
-
-
-
+* [Types of Feature Modules](guide/module-types).
diff --git a/aio/content/guide/module-types.md b/aio/content/guide/module-types.md
index 3276078bca..1e768858a7 100644
--- a/aio/content/guide/module-types.md
+++ b/aio/content/guide/module-types.md
@@ -62,7 +62,7 @@ typical characteristics, in real world apps, you may see hybrids.
A lazy-loaded routed feature module should not be imported by any module. Doing so would trigger an eager load, defeating the purpose of lazy loading.That means you won’t see them mentioned among the `AppModule` imports. An eager loaded routed feature module must be imported by another module so that the compiler learns about its components.
- Routed feature modules rarely have providers for reasons explained in Lazy Loading Feature Modules(page forthcoming). When they do, the lifetime of the provided services should be the same as the lifetime of the module. Don't provide application-wide singleton services in a routed feature module or in a module that the routed module imports.
+ Routed feature modules rarely have providers for reasons explained in [Lazy Loading Feature Modules](/guide/lazy-loading-ngmodules). When they do, the lifetime of the provided services should be the same as the lifetime of the module. Don't provide application-wide singleton services in a routed feature module or in a module that the routed module imports.
@@ -92,7 +92,7 @@ typical characteristics, in real world apps, you may see hybrids.
Service |
- Service modules provide utility services such as data access and messaging. Ideally, they consist entirely of providers and have no declarations. Angular's `HttpModule` is a good example of a service module.
+ Service modules provide utility services such as data access and messaging. Ideally, they consist entirely of providers and have no declarations. Angular's `HttpClientModule` is a good example of a service module.
The root `AppModule` is the only module that should import service modules.
@@ -110,7 +110,7 @@ typical characteristics, in real world apps, you may see hybrids.
A widget module should rarely have providers.
Import widget modules in any module whose component templates need the widgets.
-
+
|
@@ -189,4 +189,3 @@ The following table summarizes the key characteristics of each feature module gr
You may also be interested in the following:
* [Lazy Loading Modules with the Angular Router](guide/lazy-loading-ngmodules).
* [Providers](guide/providers).
-* [Types of NgModules](guide/module-types).
diff --git a/aio/content/guide/ngmodule-api.md b/aio/content/guide/ngmodule-api.md
index 98f244904d..e661cad113 100644
--- a/aio/content/guide/ngmodule-api.md
+++ b/aio/content/guide/ngmodule-api.md
@@ -19,213 +19,214 @@ into three categories:
* **Runtime:** Injector configuration via the `providers` array.
* **Composability/Grouping:** Bringing NgModules together and making them available via the `imports` and `exports` arrays.
-```ts
+```typescript
@NgModule({
- // Static, that is compiler configuration
- declarations: [], // Configure the selectors
- entryComponents: [], // Generate the host factory
+ // Static, that is compiler configuration
+ declarations: [], // Configure the selectors
+ entryComponents: [], // Generate the host factory
- // Runtime, or injector configuration
- providers: [], // Runtime injector configuration
+ // Runtime, or injector configuration
+ providers: [], // Runtime injector configuration
- // Composability / Grouping
- imports: [], // composing NgModules together
- exports: [] // making NgModules available to other parts of the app
+ // Composability / Grouping
+ imports: [], // composing NgModules together
+ exports: [] // making NgModules available to other parts of the app
})
```
## `@NgModule` metadata
-The following table summarizes the `NgModule` metadata properties.
+The following table summarizes the `@NgModule` metadata properties.
-
+
- |
- Property
- |
+
+ Property
+ |
-
- Description
- |
+
+ Description
+ |
-
+
-
+
-
- declarations
- |
+
+ declarations
+ |
-
+ |
+ A list of [declarable](guide/ngmodule-faq#q-declarable) classes,
+ (*components*, *directives*, and *pipes*) that _belong to this module_.
- A list of [declarable](guide/ngmodule-faq#q-declarable) classes,
- (*components*, *directives*, and *pipes*) that _belong to this module_.
+
+ - When compiling a template, you need to determine a set of selectors which should be used for triggering their corresponding directives.
+ -
+ The template is compiled within the context of an NgModule—the NgModule within which the template's component is declared—which determines the set of selectors using the following rules:
+
+ - All selectors of directives listed in `declarations`.
+ - All selectors of directives exported from imported NgModules.
+
+
+
-1) When compiling a template, you need to determine a set of selectors which should be used for triggering their corresponding directives.
-2) The template is compiled within a context of an `NgModule`—the `NgModule` which this template's component is declared in—which determines the set of selectors using the following rules:
- a) All selectors of directives listed in `declarations`
- b) All exported selectors of imported `NgModules`.
+ Components, directives, and pipes must belong to _exactly_ one module.
+ The compiler emits an error if you try to declare the same class in more than one module.
+ Don't re-declare a class imported from another module.
- Components, directives, and pipes must belong to _exactly_ one module.
- The compiler emits an error if you try to declare the same class in more than one module.
+ |
- Don't re-declare a class imported from another module.
+
-
+
-
+
+ providers
+ |
-
+ |
- |
- providers
- |
+ A list of dependency-injection providers.
-
+ Angular registers these providers with the NgModule's injector.
+ If it is the NgModule used for bootstrapping then it is the root injector.
+ These services become available for injection into any component, directive, pipe or service which is a child of this injector.
- A list of dependency-injection providers.
+ A lazy-loaded module has its own injector which
+ is typically a child of the application root injector.
- Angular registers these providers with the NgModule's injector.
- If it is the NgModule used for bootstrapping that it is the root injector.
+ Lazy-loaded services are scoped to the lazy module's injector.
+ If a lazy-loaded module also provides the `UserService`,
+ any component created within that module's context (such as by router navigation)
+ gets the local instance of the service, not the instance in the root application injector.
- These services become available for injection into any component, directive, pipe or service which is a child of this injector.
+ Components in external modules continue to receive the instance provided by their injectors.
- A lazy-loaded module has its own injector which
- is typically a child of the application root injector.
+ For more information on injector hierarchy and scoping, see [Providers](guide/providers).
- Lazy-loaded services are scoped to the lazy module's injector.
- If a lazy-loaded module also provides the `UserService`,
- any component created within that module's context (such as by router navigation)
- gets the local instance of the service, not the instance in the root application injector.
+ |
- Components in external modules continue to receive the instance provided by their injectors.
+
- For more information on injector hierarchy and scoping, see [Providers](guide/providers).
+
-
+
+ imports
+ |
-
+
- |
+ A list of modules which should be folded into this module. Folded means it is
+ as if all the imported NgModule's exported properties were declared here.
-
- imports
- |
+ Specifically, it is as if the list of modules whose exported components, directives, or pipes
+ are referenced by the component templates were declared in this module.
-
+ A component template can [reference](guide/ngmodule-faq#q-template-reference) another component, directive, or pipe
+ when the reference is declared in this module or if the imported module has exported it.
+ For example, a component can use the `NgIf` and `NgFor` directives only if the
+ module has imported the Angular `CommonModule` (perhaps indirectly by importing `BrowserModule`).
+ You can import many standard directives from the `CommonModule`
+ but some familiar directives belong to other modules.
+ For example, you can use `[(ngModel)]` only
+ after importing the Angular `FormsModule`.
- A list of modules which should be folded into this module. Folded means it is
- as if all of the imported NgModule properties were declared here.
+ |
- Specifically, it is as if the list of modules whose exported components, directives, or pipes
- are referenced by the component templates were declared in this module.
+
- A component template can [reference](guide/ngmodule-faq#q-template-reference) another component, directive, or pipe
- when the reference is declared in this module
- or if the imported module has exported it.
- For example, a component can use the `NgIf` and `NgFor` directives only if the
- module has imported the Angular `CommonModule` (perhaps indirectly by importing `BrowserModule`).
+
- You can import many standard directives from the `CommonModule`
- but some familiar directives belong to other modules.
- For example, you can use `[(ngModel)]` only
- after importing the Angular `FormsModule`.
-
+
+ exports
+ |
-
+
- |
+ A list of declarations—*component*, *directive*, and *pipe* classes—that
+ an importing module can use.
-
- exports
- |
+ Exported declarations are the module's _public API_.
+ A component in another module can [use](guide/ngmodule-faq#q-template-reference) _this_
+ module's `UserComponent` if it imports this module and this module exports `UserComponent`.
-
+ Declarations are private by default.
+ If this module does _not_ export `UserComponent`, then only the components within _this_
+ module can use `UserComponent`.
+ Importing a module does _not_ automatically re-export the imported module's imports.
+ Module 'B' can't use `ngIf` just because it imported module 'A' which imported `CommonModule`.
+ Module 'B' must import `CommonModule` itself.
- A list of declarations—*component*, *directive*, and *pipe* classes—that
- an importing module can use.
+ A module can list another module among its `exports`, in which case
+ all of that module's public components, directives, and pipes are exported.
- Exported declarations are the module's _public API_.
- A component in another module can [use](guide/ngmodule-faq#q-template-reference) _this_ module's `UserComponent`
- if it imports this module and this module exports `UserComponent`.
+ [Re-export](guide/ngmodule-faq#q-reexport) makes module transitivity explicit.
+ If Module 'A' re-exports `CommonModule` and Module 'B' imports Module 'A',
+ Module 'B' components can use `ngIf` even though 'B' itself didn't import `CommonModule`.
- Declarations are private by default.
- If this module does _not_ export `UserComponent`, than only the components within where the `UserComponent` has been declared can use `UserComponent.
+ |
- Importing a module does _not_ automatically re-export the imported module's imports.
- Module 'B' can't use `ngIf` just because it imported module `A` which imported `CommonModule`.
- Module 'B' must import `CommonModule` itself.
+
- A module can list another module among its `exports`, in which case
- all of that module's public components, directives, and pipes are exported.
+
- [Re-export](guide/ngmodule-faq#q-reexport) makes module transitivity explicit.
- If Module 'A' re-exports `CommonModule` and Module 'B' imports Module 'A',
- Module 'B' components can use `ngIf` even though 'B' itself didn't import `CommonModule`.
+
+ bootstrap
+ |
-
+
- |
+ A list of components that are automatically bootstrapped.
-
+ Usually there's only one component in this list, the _root component_ of the application.
-
- bootstrap
- |
+ Angular can launch with multiple bootstrap components,
+ each with its own location in the host web page.
-
+ A bootstrap component is automatically added to `entryComponents`.
+ |
- A list of components that are automatically bootstrapped.
+
- Usually there's only one component in this list, the _root component_ of the application.
+
- Angular can launch with multiple bootstrap components,
- each with its own location in the host web page.
+
+ entryComponents
+ |
- A bootstrap component is automatically added to `entryComponents`.
+
- |
+ A list of components that can be dynamically loaded into the view.
-
+ By default, an Angular app always has at least one entry component, the root component, `AppComponent`. Its purpose is to serve as a point of entry into the app, that is, you bootstrap it to launch the app.
-
+ Routed components are also _entry components_ because they need to be loaded dynamically.
+ The router creates them and drops them into the DOM near a ``.
-
- entryComponents
- |
+ While the bootstrapped and routed components are _entry components_,
+ you don't have to add them to a module's `entryComponents` list,
+ as they are added implicitly.
-
+ Angular automatically adds components in the module's `bootstrap` and route definitions into the `entryComponents` list.
+ That leaves only components bootstrapped using one of the imperative techniques, such as [`ViewComponentRef.createComponent()`](https://angular.io/api/core/ViewContainerRef#createComponent) as undiscoverable.
- A list of components that can be dynamically loaded into the view.
+ Dynamic component loading is not common in most apps beyond the router. If you need to dynamically load components, you must add these components to the `entryComponents` list yourself.
- By default, an Angular app always has at least one entry component, the root component, `AppComponent`. Its purpose is to serve as a point of entry into the app, that is, you bootstrap it to launch the app.
+ For more information, see [Entry Components](guide/entry-components).
- Routed components are also _entry components_ because they need to be loaded dynamically.
- The router creates them and drops them into the DOM near a ``.
+ |
- While the bootstrapped and routed components are _entry components_,
- you don't have to add them to a module's `entryComponents` list,
- as they are added implicitly.
-
- Angular automatically adds components in the module's `bootstrap` and route definitions into the `entryComponents` list.
-
-That leaves only components bootstrapped using one of the imperative techniques, such as [`ViewComponentRef.createComponent()`](https://angular.io/api/core/ViewContainerRef#createComponent) as undiscoverable.
-
- Dynamic component loading is not common in most apps beyond the router. If you need to dynamically load components, you must add these components to the `entryComponents` list yourself.
-
- For more information, see [Entry Components](guide/entry-components).
-
-
-
+
@@ -238,7 +239,4 @@ You may also be interested in the following:
* [Feature Modules](guide/feature-modules).
* [Entry Components](guide/entry-components).
* [Providers](guide/providers).
-* [Types of NgModules](guide/module-types).
-
-
-
+* [Types of Feature Modules](guide/module-types).
diff --git a/aio/content/guide/ngmodule-faq.md b/aio/content/guide/ngmodule-faq.md
index 31af24be1f..651b8875fa 100644
--- a/aio/content/guide/ngmodule-faq.md
+++ b/aio/content/guide/ngmodule-faq.md
@@ -40,7 +40,7 @@ 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.
+For example, don't declare `FORMS_DIRECTIVES` from `@angular/forms` because the `FormsModule` already declares it.
* Module classes.
* Service classes.
@@ -120,7 +120,7 @@ Importing `CommonModule` also frees feature modules for use on _any_ target plat
-
+{@a q-reimport}
## What if I import the same module twice?
@@ -136,13 +136,13 @@ Angular doesn't like NgModules with circular references, so don't let Module 'A'
-
+{@a q-reexport}
## What should I export?
Export [declarable](guide/bootstrapping#the-declarations-array) classes that components in _other_ NgModules
are able to reference in their templates. These are your _public_ classes.
-If you don't export a class, it stays _private_, visible only to other component
+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
@@ -164,7 +164,7 @@ If you don't want another NgModule to see it, don't export it.
Such [entry components](guide/ngmodule-faq#q-entry-component-defined) 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 `HttpModule` because it doesn't export anything.
+For example, there's no point in re-exporting `HttpClientModule` because it doesn't export anything.
It's only purpose is to add http service providers to the application as a whole.
@@ -183,14 +183,13 @@ Angular's own `BrowserModule` exports a couple of NgModules like this:
```typescript
exports: [CommonModule, ApplicationModule]
-
```
An NgModule can export a combination of its own declarations, selected imported classes, and imported NgModules.
Don't bother re-exporting pure service modules.
Pure service modules don't export [declarable](guide/bootstrapping#the-declarations-array) classes that another NgModule could use.
-For example, there's no point in re-exporting `HttpModule` because it doesn't export anything.
+For example, there's no point in re-exporting `HttpClientModule` because it doesn't export anything.
It's only purpose is to add http service providers to the application as a whole.
@@ -209,6 +208,7 @@ You add that result to the `imports` list of the root `AppModule`.
Only call and import a `.forRoot()` result in the root application module, `AppModule`.
Importing it in any other module, particularly in a lazy-loaded module,
is contrary to the intent and will likely produce a runtime error.
+For more information, see [Singleton Services](guide/singleton-services).
`RouterModule` also offers a `forChild` static method for configuring the routes of lazy-loaded modules.
@@ -237,7 +237,7 @@ This is by design.
Extensibility through NgModule imports is a primary goal of the NgModule system.
Merging NgModule providers into the application injector
makes it easy for a module library to enrich the entire application with new services.
-By adding the `HttpModule` once, every application component can make HTTP requests.
+By adding the `HttpClientModule` once, every application component can make HTTP requests.
However, this might feel like an unwelcome surprise if you expect the module's services
to be visible only to the components declared by that feature module.
@@ -247,9 +247,7 @@ not just the classes declared in the `HeroModule`.
-
-{@ q-lazy-loaded-module-provider-visibility}
-
+{@a q-lazy-loaded-module-provider-visibility}
## Why is a service provided in a lazy-loaded module visible only to that module?
@@ -303,10 +301,10 @@ That's also usually the best place to configure, wrap, and override them.
Suppose a module requires a customized `HttpBackend` that adds a special header for all Http requests.
If another module elsewhere in the application also customizes `HttpBackend`
-or merely imports the `HttpModule`, it could override this module's `HttpBackend` provider,
+or merely imports the `HttpClientModule`, it could override this module's `HttpBackend` provider,
losing the special header. The server will reject http requests from this module.
-To avoid this problem, import the `HttpModule` only in the `AppModule`, the application _root module_.
+To avoid this problem, import the `HttpClientModule` only in the `AppModule`, the application _root module_.
If you must guard against this kind of "provider corruption", *don't rely on a launch-time module's `providers`.*
@@ -337,9 +335,8 @@ Define child routes and let the router load module components into that outlet.
-
+{@a q-root-component-or-module}
-{@ q-root-component-or-module}
## Should I add application-wide providers to the root `AppModule` or the root `AppComponent`?
@@ -356,7 +353,7 @@ More generally, [prefer registering providers in NgModules](guide/ngmodule-faq#q
Discussion
Angular registers all startup module providers with the application root injector.
-The services that root injector providers create have application scope, which
+The services that root injector providers create have application scope, which
means they are available to the entire application.
Certain services, such as the `Router`, only work when you register them in the application root injector.
@@ -367,14 +364,13 @@ They have component scope.
The `AppComponent`'s injector is a child of the root injector, one down in the injector hierarchy.
For applications that don't use the router, that's almost the entire application.
-But in routed applications, routing operates at the root level
+But in routed applications, routing operates at the root level
where `AppComponent` services don't exist.
This means that lazy-loaded modules can't reach them.
-
-{@ q-component-or-module}
+{@a q-component-or-module}
## Should I add other providers to a module or a component?
@@ -395,15 +391,14 @@ not the root `AppComponent`.
-
+{@a q-why-bad}
-{@ q-why-bad}
## Why is it bad if a shared module provides a service to a lazy-loaded module?
### The eagerly loaded scenario
-When an eagerly loaded module provides a service, for example a `UserService`, that service is available application-wide. If the root module provides `UserService` and
-imports another module that provides the same `UserService`, Angular registers one of
+When an eagerly loaded module provides a service, for example a `UserService`, that service is available application-wide. If the root module provides `UserService` and
+imports another module that provides the same `UserService`, Angular registers one of
them in the root app injector (see [What if I import the same module twice?](guide/ngmodule-faq#q-reimport)).
Then, when some component injects `UserService`, Angular finds it in the app root injector,
@@ -480,7 +475,7 @@ Here is a custom constructor for an NgModule called `CoreModule`.
-{@a q-entry-component-defined}
+{@a q-entry-component-defined}
## What is an `entry component`?
@@ -488,7 +483,7 @@ An entry component is any component that Angular loads _imperatively_ by type.
A component loaded _declaratively_ via its selector is _not_ an entry component.
-Angular loads a component declaratively when
+Angular loads a component declaratively when
using the component's selector to locate the element in the template.
Angular then creates the HTML representation of the component and inserts it into the DOM at the selected element. These aren't entry components.
@@ -509,13 +504,13 @@ For more information, see [Entry Components](guide/entry-components).
## What's the difference between a _bootstrap_ component and an _entry component_?
A bootstrapped component _is_ an [entry component](guide/ngmodule-faq#q-entry-component-defined)
-that Angular loads into the DOM during the bootstrap (application launch) process.
+that Angular loads into the DOM during the bootstrap process (application launch).
Other entry components are loaded dynamically by other means, such as with the router.
The `@NgModule.bootstrap` property tells the compiler that this is an entry component _and_
it should generate code to bootstrap the application with this component.
-There's no need to list a component in both the `bootstrap` and `entryComponent` lists,
+There's no need to list a component in both the `bootstrap` and `entryComponents` lists,
although doing so is harmless.
For more information, see [Entry Components](guide/entry-components).
@@ -587,7 +582,7 @@ Import the `SharedModule` in your _feature_ modules,
both those loaded when the app starts and those you lazy load later.
### `CoreModule`
-`CoreModule` is a conventional name for an `NgModule` with `providers` for
+`CoreModule` is a conventional name for an `NgModule` with `providers` for
the singleton services you load when the application starts.
Import `CoreModule` in the root `AppModule` only.
@@ -596,20 +591,20 @@ Never import `CoreModule` in any other module.
Consider making `CoreModule` a pure services module
with no `declarations`.
-For more information, see [Sharing NgModules](guide/sharing-ngmodules)
+For more information, see [Sharing NgModules](guide/sharing-ngmodules)
and [Singleton Services](guide/singleton-services).
### Feature Modules
-Feature modules are modules you create around specific application business domains, user workflows, and utility collections. They support your app by containing a particular feature,
-such as routes, services, widgets, etc. To conceptualize what a feature module might be in your
-app, consider that if you would put the files related to a certain functionality, like a search,
-in one folder, that the contents of that folder would be a feature module that you might call
-your `SearchModule`. It would contain all of the components, routing, and templates that
+Feature modules are modules you create around specific application business domains, user workflows, and utility collections. They support your app by containing a particular feature,
+such as routes, services, widgets, etc. To conceptualize what a feature module might be in your
+app, consider that if you would put the files related to a certain functionality, like a search,
+in one folder, that the contents of that folder would be a feature module that you might call
+your `SearchModule`. It would contain all of the components, routing, and templates that
would make up the search functionality.
-For more information, see [Feature Modules](guide/feature-modules) and
-[Module Types](guide/module-types)
+For more information, see [Feature Modules](guide/feature-modules) and
+[Module Types](guide/module-types)
@@ -621,7 +616,7 @@ In modern JavaScript, every file is a module
(see the [Modules](http://exploringjs.com/es6/ch_modules.html) page of the Exploring ES6 website).
Within each file you write an `export` statement to make parts of the module public.
-An Angular NgModule is a class with the `@NgModule` decorator—JavaScript modules
+An Angular NgModule is a class with the `@NgModule` decorator—JavaScript modules
don't have to have the `@NgModule` decorator. Angular's `NgModule` has `imports` and `exports` and they serve a similar purpose.
You _import_ other NgModules so you can use their exported classes in component templates.
@@ -631,7 +626,7 @@ For more information, see [JavaScript Modules vs. NgModules](guide/ngmodule-vs-j
-
+{@a q-template-reference}
## How does Angular find components, directives, and pipes in a template?
What is a template reference?
@@ -647,9 +642,7 @@ or exported by a module that this module imports.
-
-
-{@ q-angular-compiler}
+{@a q-angular-compiler}
## What is the Angular compiler?
@@ -671,4 +664,3 @@ the Angular compiler incorporates them into compiled component code too.
`@NgModule` metadata tells the Angular compiler what components to compile for this module and
how to link this module with other modules.
-
diff --git a/aio/content/guide/ngmodule-vs-jsmodule.md b/aio/content/guide/ngmodule-vs-jsmodule.md
index 4b9832ac9f..0caafac5fb 100644
--- a/aio/content/guide/ngmodule-vs-jsmodule.md
+++ b/aio/content/guide/ngmodule-vs-jsmodule.md
@@ -12,14 +12,14 @@ though they organize it differently, Angular apps rely on both.
In JavaScript, modules are individual files with JavaScript code in them. To make what’s in them available, you write an export statement, usually after the relevant code, like this:
-```javascript
+```typescript
export class AppComponent { ... }
```
Then, when you need that file’s code in another file, you import it like this:
-```javascript
-import { AppComponent } from './app.component';
+```typescript
+import { AppComponent } from './app.component';
```
JavaScript modules help you namespace, preventing accidental global variables.
@@ -31,27 +31,23 @@ NgModules are classes decorated with `@NgModule`. The `@NgModule` decorator’s
The `AppModule` generated from the Angular CLI demonstrates both kinds of modules in action:
-```javascript
+```typescript
/* These are JavaScript import statements. Angular doesn’t know anything about these. */
import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
-import { FormsModule } from '@angular/forms';
-import { HttpModule } from '@angular/http';
import { AppComponent } from './app.component';
/* The @NgModule decorator lets Angular know that this is an NgModule. */
@NgModule({
-declarations: [
- AppComponent
-],
-imports: [ /* These are NgModule imports. */
- BrowserModule,
- FormsModule,
- HttpModule
-],
-providers: [],
-bootstrap: [AppComponent]
+ declarations: [
+ AppComponent
+ ],
+ imports: [ /* These are NgModule imports. */
+ BrowserModule
+ ],
+ providers: [],
+ bootstrap: [AppComponent]
})
export class AppModule { }
```
@@ -76,5 +72,3 @@ For more information on NgModules, see:
* [Bootstrapping](guide/bootstrapping).
* [Frequently used modules](guide/frequent-ngmodules).
* [Providers](guide/providers).
-
-
diff --git a/aio/content/guide/ngmodules.md b/aio/content/guide/ngmodules.md
index a55aa2e516..f68b685012 100644
--- a/aio/content/guide/ngmodules.md
+++ b/aio/content/guide/ngmodules.md
@@ -8,12 +8,12 @@ A basic understanding of the following concepts:
-**NgModules** configure the injector and the compiler and help organize related things together
+**NgModules** configure the injector and the compiler and help organize related things together.
An NgModule is a class marked by the `@NgModule` decorator.
-`@NgModule` takes a metadata object that describes how to compile a component's templates and how to create an injector at runtime.
+`@NgModule` takes a metadata object that describes how to compile a component's template and how to create an injector at runtime.
It identifies the module's own components, directives, and pipes,
-making some of them public, through the `exports` property public, so that external components can use them.
+making some of them public, through the `exports` property, so that external components can use them.
`@NgModule` can also add service providers to the application dependency injectors.
For an example app showcasing all the techniques that NgModules related pages
@@ -25,7 +25,7 @@ section.
Modules are a great way to organize an application and extend it with capabilities from external libraries.
-Angular libraries are NgModules, such as `FormsModule`, `HttpModule`, and `RouterModule`.
+Angular libraries are NgModules, such as `FormsModule`, `HttpClientModule`, and `RouterModule`.
Many third-party libraries are available as NgModules such as
Material Design,
Ionic, and
diff --git a/aio/content/guide/sharing-ngmodules.md b/aio/content/guide/sharing-ngmodules.md
index e971294463..939a8dfd4b 100644
--- a/aio/content/guide/sharing-ngmodules.md
+++ b/aio/content/guide/sharing-ngmodules.md
@@ -21,15 +21,17 @@ Consider the following module from an imaginary app:
```typescript
-import { NgModule } from '@angular/core';
-import { CommonModule } from '@angular/common';
-import { FormsModule } from '@angular/forms';
-import { OrdersPipe } from './orders.pipe';
-import { NewItemDirective } from './newitem.directive';
+import { CommonModule } from '@angular/common';
+import { NgModule } from '@angular/core';
+import { FormsModule } from '@angular/forms';
+import { CustomerComponent } from './customer.component';
+import { NewItemDirective } from './new-item.directive';
+import { OrdersPipe } from './orders.pipe';
+
@NgModule({
imports: [ CommonModule ],
- declarations: [ OrdersPipe, NewItemDirective ],
- exports: [ OrdersPipe, NewItemDirective,
+ declarations: [ CustomerComponent, NewItemDirective, OrdersPipe ],
+ exports: [ CustomerComponent, NewItemDirective, OrdersPipe,
CommonModule, FormsModule ]
})
export class SharedModule { }
@@ -56,9 +58,9 @@ having to import it directly into the `@NgModule` decorator.
There is an important distinction between using another module's component and
using a service from another module. Import modules when you want to use
-directives, 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.
+directives, 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.
-The most common way to get a hold of sharedservices is through Angular
+The most common way to get a hold of shared services is through Angular
[dependency injection](guide/dependency-injection), rather than through the module system (importing a module will result in a new service instance, which is not a typical usage).
To read about sharing services, see [Providers](guide/providers).
@@ -70,7 +72,4 @@ To read about sharing services, see [Providers](guide/providers).
You may also be interested in the following:
* [Providers](guide/providers).
-* [Types of Modules](guide/module-types).
-
-
-
+* [Types of Feature Modules](guide/module-types).
diff --git a/aio/content/guide/singleton-services.md b/aio/content/guide/singleton-services.md
index ea19f9c777..935dda52cb 100644
--- a/aio/content/guide/singleton-services.md
+++ b/aio/content/guide/singleton-services.md
@@ -14,7 +14,13 @@ showcasing all the documented features of NgModules.
## Providing a singleton service
-An injector created from a module definition will have services which are singletons with respect to that injector. To control the lifetime of services, one controls the creation and destruction of injectors. For example, a route will have an associated module. When the route is activated, an injector is created from that module as a child of the current injector. When you navigate away from the route, the injector is destroyed. This means that services declared in a route module will have a lifetime equal to that of the route. Similarly, services provided in an application module will have the same lifetime of the application, hence singleton.
+An injector created from a module definition will have services which are singletons with respect to
+that injector. To control the lifetime of services, one controls the creation and destruction of
+injectors. For example, a route will have an associated module. When the route is activated, an
+injector is created from that module as a child of the current injector. When you navigate away from
+the route, the injector is destroyed. This means that services declared in a route module will have
+a lifetime equal to that of the route. Similarly, services provided in an application module will
+have the same lifetime of the application, hence singleton.
The following example module is called, as a convention, `CoreModule`. This use of `@NgModule` creates organizational infrastructure and gives you
a way of providing services from a designated NgModule.
@@ -47,8 +53,8 @@ As a general rule, import modules with providers _exactly once_,
preferably in the application's _root module_.
That's also usually the best place to configure, wrap, and override them.
-For more detailed information on services, see
-[part 5](tutorial/toh-pt4) of the [Tour of Heroes tutorial](tutorial).
+For more detailed information on services, see the [Services](tutorial/toh-pt4) chapter of the
+[Tour of Heroes tutorial](tutorial).
## `forRoot()`
@@ -171,9 +177,6 @@ Here are the two files in their entirety for reference:
## More on NgModules
You may also be interested in:
-* [Sharing NgModules](guide/singleton-services), which elaborates on the concepts covered on this page.
+* [Sharing Modules](guide/sharing-ngmodules), which elaborates on the concepts covered on this page.
* [Lazy Loading Modules](guide/lazy-loading-ngmodules).
* [NgModule FAQ](guide/ngmodule-faq).
-
-
-
diff --git a/aio/content/navigation.json b/aio/content/navigation.json
index 00944edb07..670f203a52 100644
--- a/aio/content/navigation.json
+++ b/aio/content/navigation.json
@@ -240,8 +240,8 @@
},
{
"url": "guide/module-types",
- "title": "Types of NgModules",
- "tooltip": "Description of the different types of feature module."
+ "title": "Types of Feature Modules",
+ "tooltip": "Description of the different types of feature modules."
},
{
"url": "guide/entry-components",