honeymoose
/
angular-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: Edits to remove jargon in Reference NgModules (#42182) 

PR Close #42182
This commit is contained in:
Teri Glover 2021-05-19 19:05:03 +00:00 committed by Jessica Janiuk
parent 2d0ff0a5d3
commit a5b5136843
12 changed files with 78 additions and 78 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
aio/content/guide/bootstrapping.md
View File

@ -114,7 +114,7 @@ And in the same file, add it to the `@NgModule` `declarations` array:
Now you could use your `ItemDirective` in a component. This example uses `AppModule`, but you'd do it the same way for a feature module. For more about directives, see [Attribute Directives](guide/attribute-directives) and [Structural Directives](guide/structural-directives). You'd also use the same technique for [pipes](guide/pipes) and components.
Remember, components, directives, and pipes belong to one module only. You only need to declare them once in your app because you share them by importing the necessary modules. This saves you time and helps keep your app lean.
Remember, components, directives, and pipes belong to one module only. You only need to declare them once in your application because you share them by importing the necessary modules. This saves you time and helps keep your application lean.
{@a imports}
@ -143,7 +143,7 @@ the class was imported from another module.
## The `providers` array
The providers array is where you list the services the app needs. When
The providers array is where you list the services the application needs. When
you list services here, they are available app-wide. You can scope
them when using feature modules and lazy loading. For more information, see
[Providers](guide/providers).
@ -169,5 +169,5 @@ root module's `bootstrap` array.
## More about Angular Modules
For more on NgModules you're likely to see frequently in apps,
For more on NgModules you're likely to see frequently in applications,
see [Frequently Used Modules](guide/frequent-ngmodules).

4
aio/content/guide/entry-components.md
View File

@ -89,12 +89,12 @@ All router components must be entry components. Because this would require you t
</div>
Though the `@NgModule` decorator has an `entryComponents` array, most of the time
you won't have to explicitly set any entry components because Angular adds components listed in `@NgModule.bootstrap` and those in route definitions to entry components automatically. Though these two mechanisms account for most entry components, if your app happens to bootstrap or dynamically load a component by type imperatively,
you won't have to explicitly set any entry components because Angular adds components listed in `@NgModule.bootstrap` and those in route definitions to entry components automatically. Though these two mechanisms account for most entry components, if your application happens to bootstrap or dynamically load a component by type imperatively,
you must add it to `entryComponents` explicitly.
### `entryComponents` and the compiler
For production apps you want to load the smallest code possible.
For production applications you want to load the smallest code possible.
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.

12
aio/content/guide/feature-modules.md
View File

@ -2,16 +2,16 @@
Feature modules are NgModules for the purpose of organizing code.
For the final sample app with a feature module that this page describes,
For the final sample application with a feature module that this page describes,
see the <live-example></live-example>.
<hr>
As your app grows, you can organize code relevant for a specific feature.
As your application grows, you can organize code relevant for a specific feature.
This helps apply clear boundaries for features. With feature modules,
you can keep code related to a specific functionality or feature
separate from other code. Delineating areas of your
app helps with collaboration between developers and teams, separating
application helps with collaboration between developers and teams, separating
directives, and managing the size of the root module.
@ -20,14 +20,14 @@ directives, and managing the size of the root module.
A feature module is an organizational best practice, as opposed to a concept of the core Angular API. A feature module delivers a cohesive set of functionality focused on a
specific application need such as a user workflow, routing, or forms.
While you can do everything within the root module, feature modules
help you partition the app into focused areas. A feature module
help you partition the application into focused areas. A feature module
collaborates with the root module and with other modules through
the services it provides and the components, directives, and
pipes that it shares.
## How to make a feature module
Assuming you already have an app that you created with the [Angular CLI](cli), create a feature
Assuming you already have an application that you created with the [Angular CLI](cli), 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 "Module" suffix from the name because the CLI appends it:
@ -53,7 +53,7 @@ import { CommonModule } from '@angular/common';
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.
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 application for the browser which needs to be done only once.
The `declarations` array is available for you to add declarables, which
are components, directives, and pipes that belong exclusively to this particular module. To add a component, enter the following command at the command line where `customer-dashboard` is the directory where the CLI generated the feature module and `CustomerDashboard` is the name of the component:

12
aio/content/guide/frequent-ngmodules.md
View File

@ -1,6 +1,6 @@
# Frequently-used modules
An Angular app needs at least one module that serves as the root module.
An Angular application needs at least one module that serves as the root module.
As you add features to your app, you can add them in modules.
The following are frequently used Angular modules with examples
of some of the things they contain:
@ -25,7 +25,7 @@ of some of the things they contain:
<tr>
<td><code>BrowserModule</code></td>
<td><code>@angular/platform-browser</code></td>
<td>When you want to run your app in a browser</td>
<td>When you want to run your application in a browser</td>
</tr>
<tr>
@ -64,7 +64,7 @@ of some of the things they contain:
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 [Angular CLI](cli),
`imports` array. For example, in the basic application generated by the [Angular CLI](cli),
`BrowserModule` is the first import at the top of the `AppModule`,
`app.module.ts`.
@ -101,10 +101,10 @@ directives such as `ngIf` and `ngFor`. Additionally, `BrowserModule`
re-exports `CommonModule` making all of its directives available
to any module that imports `BrowserModule`.
For apps that run in the browser, import `BrowserModule` in the
For applications that run in the browser, import `BrowserModule` in the
root `AppModule` because it provides services that are essential
to launch and run a browser app. `BrowserModule`’s providers
are for the whole app so it should only be in the root module,
to launch and run a browser application. `BrowserModule`’s providers
are for the whole application so it should only be in the root module,
not in feature modules. Feature modules only need the common
directives in `CommonModule`; they don’t need to re-install app-wide providers.

16
aio/content/guide/module-types.md
View File

@ -4,7 +4,7 @@ This topic provides a conceptual overview of the different categories of [NgModu
These categories are not cast in stone—they are suggestions.
You may want to create NgModules for other purposes, or combine the characteristics of some of these categories.
NgModules are a great way to organize an app and keep code related to a specific functionality or feature separate from other code.
NgModules are a great way to organize an application and keep code related to a specific functionality or feature separate from other code.
Use NgModules to consolidate [components](guide/glossary#component "Definition of component"), [directives](guide/glossary#directive "Definition of directive"), and [pipes](guide/glossary#pipe "Definition of pipe)") into cohesive blocks of functionality.
Focus each block on a feature or business domain, a workflow or navigation flow, a common collection of utilities, or one or more [providers](guide/glossary#provider "Definition of provider") for [services](guide/glossary#service "Definition of service").
@ -12,14 +12,14 @@ For more about NgModules, see [Organizing your app with NgModules](guide/ngmodul
<div class="alert is-helpful">
For the example app used in NgModules-related topics, see the <live-example name="ngmodules"></live-example>.
For the example application used in NgModules-related topics, see the <live-example name="ngmodules"></live-example>.
</div>
## Summary of NgModule categories
All apps start by [bootstrapping a root NgModule](guide/bootstrapping "Launching an app with a root NgModule").
You can organize your other NgModules any way you wish.
All applications start by [bootstrapping a root NgModule](guide/bootstrapping "Launching an app with a root NgModule").
You can organize your other NgModules any way you want.
This topic provides some guidelines for the following general categories of NgModules:
@ -108,14 +108,14 @@ The following table summarizes the key characteristics of each category.
## Domain NgModules
Use a domain NgModule to deliver a user experience dedicated to a particular feature or app domain, such as editing a customer or placing an order.
Use a domain NgModule to deliver a user experience dedicated to a particular feature or application domain, such as editing a customer or placing an order.
One example is `ContactModule` in the <live-example name="ngmodules"></live-example>.
A domain NgModule organizes the code related to a certain function, containing all of the components, routing, and templates that make up the function.
Your top component in the domain NgModule acts as the feature or domain's root, and is the only component you export.
Private supporting subcomponents descend from it.
Import a domain NgModule exactly once into another NgModule, such as a domain NgModule, or into the root NgModule (`AppModule`) of an app that contains only a few NgModules.
Import a domain NgModule exactly once into another NgModule, such as a domain NgModule, or into the root NgModule (`AppModule`) of an application that contains only a few NgModules.
Domain NgModules consist mostly of declarations.
You rarely include providers.
@ -204,7 +204,7 @@ It would rarely have providers.
## Shared NgModules
Put commonly used directives, pipes, and components into one NgModule, typically named `SharedModule`, and then import just that NgModule wherever you need it in other parts of your app.
Put commonly used directives, pipes, and components into one NgModule, typically named `SharedModule`, and then import just that NgModule wherever you need it in other parts of your application.
You can import the shared NgModule in your domain NgModules, including [lazy-loaded NgModules](guide/lazy-loading-ngmodules "Lazy-loading an NgModule").
One example is `SharedModule` in the <live-example name="ngmodules"></live-example>, which provides the `AwesomePipe` custom pipe and `HighlightDirective` directive.
@ -223,6 +223,6 @@ You may also be interested in the following:
If you want to manage NgModule loading and the use of dependencies and services, see the following:
* To learn about loading NgModules eagerly when the app starts, or lazy-loading NgModules asynchronously by the router, see [Lazy-loading feature modules](guide/lazy-loading-ngmodules).
* To learn about loading NgModules eagerly when the application starts, or lazy-loading NgModules asynchronously by the router, see [Lazy-loading feature modules](guide/lazy-loading-ngmodules).
* To understand how to provide a service or other dependency for your app, see [Providing Dependencies for an NgModule](guide/providers "Providing Dependencies for an NgModule").
* To learn how to create a singleton service to use in NgModules, see [Making a service a singleton](guide/singleton-services "Making a service a singleton").

12
aio/content/guide/ngmodule-api.md
View File

@ -1,13 +1,13 @@
# NgModule API
At a high level, NgModules are a way to organize Angular apps
At a high level, NgModules are a way to organize Angular applications
and they accomplish this through the metadata in the `@NgModule`
decorator.
The metadata falls into three categories:
* **Static:** Compiler configuration which tells the compiler about directive selectors and where in templates the directives should be applied through selector matching. This is configured via the `declarations` array.
* **Runtime:** Injector configuration via the `providers` array.
* **Composability/Grouping:** Bringing NgModules together and making them available via the `imports` and `exports` arrays.
* **Static:** Compiler configuration which tells the compiler about directive selectors and where in templates the directives should be applied through selector matching. This is configured using the `declarations` array.
* **Runtime:** Injector configuration using the `providers` array.
* **Composability/Grouping:** Bringing NgModules together and making them available using the `imports` and `exports` arrays.
```typescript
@NgModule({
@ -196,7 +196,7 @@ The following table summarizes the `@NgModule` metadata properties.
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.
By default, an Angular application 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 application.
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 `<router-outlet>`.
@ -209,7 +209,7 @@ The following table summarizes the `@NgModule` metadata properties.
That leaves only components bootstrapped using one of the imperative techniques, such as [`ViewComponentRef.createComponent()`](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.
Dynamic component loading is not common in most applications 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).

38
aio/content/guide/ngmodule-faq.md
View File

@ -27,7 +27,7 @@ Add only [declarable](guide/bootstrapping#the-declarations-array) classes to an
Do *not* declare the following:
* A class that's already declared in another module, whether an app module, @NgModule, or third-party module.
* A class that's already declared in another module, whether an application 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.
@ -47,7 +47,7 @@ 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 imported from another application 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.
@ -89,11 +89,11 @@ Import [BrowserModule](guide/ngmodule-faq#q-browser-vs-common-module) only in th
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` provides services that are essential to launch and run a browser application.
`BrowserModule` also re-exports `CommonModule` from `@angular/common`,
which means that components in the `AppModule` also have access to
the Angular directives every app needs, such as `NgIf` and `NgFor`.
the Angular directives every application needs, such as `NgIf` and `NgFor`.
Do not import `BrowserModule` in any other module.
*Feature modules* and *lazy-loaded modules* should import `CommonModule` instead.
@ -172,7 +172,7 @@ Its only purpose is to add http service providers to the application as a whole.
The `forRoot()` static method is a convention that makes it easy for developers to configure services and providers that are intended to be singletons. A good example of `forRoot()` is the `RouterModule.forRoot()` method.
Apps pass a `Routes` array to `RouterModule.forRoot()` in order to configure the app-wide `Router` service with routes.
Applications pass a `Routes` array to `RouterModule.forRoot()` in order to configure the app-wide `Router` service with routes.
`RouterModule.forRoot()` returns a [ModuleWithProviders](api/core/ModuleWithProviders).
You add that result to the `imports` list of the root `AppModule`.
@ -368,9 +368,9 @@ not the root `AppComponent`.
### 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
them in the root app injector (see [What if I import the same module twice?](guide/ngmodule-faq#q-reimport)).
them in the root application 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,
Then, when some component injects `UserService`, Angular finds it in the application root injector,
and delivers the app-wide singleton service. No problem.
### The lazy loaded scenario
@ -386,7 +386,7 @@ and creates a _new_ instance of the `UserService`.
This is an entirely different `UserService` instance
than the app-wide singleton version that Angular injected in one of the eagerly loaded components.
This scenario causes your app to create a new instance every time, instead of using the singleton.
This scenario causes your application to create a new instance every time, instead of using the singleton.
<!--KW--What does this cause? I wasn't able to get the suggestion of this to work from
the current FAQ:
To demonstrate, run the <live-example name="ngmodule">live example</live-example>.
@ -405,7 +405,7 @@ For a lazy-loaded NgModule, Angular creates a _child injector_ and adds the modu
This means that an NgModule behaves differently depending on whether it's loaded during application start
or lazy-loaded later. Neglecting that difference can lead to [adverse consequences](guide/ngmodule-faq#q-why-bad).
Why doesn't Angular add lazy-loaded providers to the app root injector as it does for eagerly loaded NgModules?
Why doesn't Angular add lazy-loaded providers to the application root injector as it does for eagerly loaded NgModules?
The answer is grounded in a fundamental characteristic of the Angular dependency-injection system.
An injector can add providers _until it's first used_.
@ -413,11 +413,11 @@ Once an injector starts creating and delivering services, its provider list is f
When an applications starts, Angular first configures the root injector with the providers of all eagerly loaded NgModules
_before_ creating its first component and injecting any of the provided services.
Once the application begins, the app root injector is closed to new providers.
Once the application begins, the application root injector is closed to new providers.
Time passes and application logic triggers lazy loading of an NgModule.
Angular must add the lazy-loaded module's providers to an injector somewhere.
It can't add them to the app root injector because that injector is closed to new providers.
It can't add them to the application root injector because that injector is closed to new providers.
So Angular creates a new child injector for the lazy-loaded module context.
@ -429,7 +429,7 @@ Importing the module a second time by lazy loading a module could [produce erran
that may be difficult to detect and diagnose.
To prevent this issue, write a constructor that attempts to inject the module or service
from the root app injector. If the injection succeeds, the class has been loaded a second time.
from the root application injector. If the injection succeeds, the class has been loaded a second time.
You can throw an error or take other remedial action.
Certain NgModules, such as `BrowserModule`, implement such a guard.
@ -443,7 +443,7 @@ Here is a custom constructor for an NgModule called `GreetingModule`.
An entry component is any component that Angular loads _imperatively_ by type.
A component loaded _declaratively_ via its selector is _not_ an entry component.
A component loaded _declaratively_ by way of its selector is _not_ an entry component.
Angular loads a component declaratively when
using the component's selector to locate the element in the template.
@ -486,7 +486,7 @@ Components listed in `@NgModule.bootstrap` are added automatically.
Components referenced in router configuration are added automatically.
These two mechanisms account for almost all entry components.
If your app happens to bootstrap or dynamically load a component _by type_ in some other manner,
If your application happens to bootstrap or dynamically load a component _by type_ in some other manner,
you must add it to `entryComponents` explicitly.
Although it's harmless to add components to this list,
@ -499,7 +499,7 @@ For more information, see [Entry Components](guide/entry-components).
## Why does Angular need _entryComponents_?
The reason is _tree shaking_. For production apps you want to load the smallest, fastest code possible. The code should contain only the classes that you actually need.
The reason is _tree shaking_. For production applications you want to load the smallest, fastest code possible. The code should contain only the classes that you actually need.
It should exclude a component that's never used, whether or not that component is declared.
In fact, many libraries declare and export components you'll never use.
@ -521,12 +521,12 @@ the compiler omits it.
## What kinds of modules should I have and how should I use them?
Every app is different. Developers have various levels of experience and comfort with the available choices.
Every application is different. Developers have various levels of experience and comfort with the available choices.
Some suggestions and guidelines appear to have wide appeal.
### `SharedModule`
`SharedModule` is a conventional name for an `NgModule` with the components, directives, and pipes that you use
everywhere in your app. This module should consist entirely of `declarations`,
everywhere in your application. This module should consist entirely of `declarations`,
most of them exported.
The `SharedModule` may re-export other widget modules, such as `CommonModule`,
@ -536,11 +536,11 @@ The `SharedModule` should not have `providers` for reasons [explained previously
Nor should any of its imported or re-exported modules have `providers`.
Import the `SharedModule` in your _feature_ modules,
both those loaded when the app starts and those you lazy load later.
both those loaded when the application starts and those you lazy load later.
### 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,
Feature modules are modules you create around specific application business domains, user workflows, and utility collections. They support your application 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

16
aio/content/guide/ngmodule-vs-jsmodule.md
View File

@ -1,11 +1,11 @@
# JavaScript modules vs. NgModules
JavaScript modules and NgModules can help you modularize your code, but they are very different.
Angular apps rely on both kinds of modules.
Angular applications rely on both kinds of modules.
## JavaScript modules: Files containing code
A [JavaScript module](https://javascript.info/modules "JavaScript.Info - Modules") is an individual file with JavaScript code, usually containing a class or a library of functions for a specific purpose within your app.
A [JavaScript module](https://javascript.info/modules "JavaScript.Info - Modules") is an individual file with JavaScript code, usually containing a class or a library of functions for a specific purpose within your application.
JavaScript modules let you spread your work across multiple files.
<div class="alert is-helpful">
@ -36,15 +36,15 @@ The Angular framework itself is loaded as a set of JavaScript modules.
## NgModules: Classes with metadata for compiling
An [NgModule](guide/glossary#ngmodule "Definition of NgModule") is a class marked by the `@NgModule` decorator with a metadata object that describes how that particular part of the app fits together with the other parts.
An [NgModule](guide/glossary#ngmodule "Definition of NgModule") is a class marked by the `@NgModule` decorator with a metadata object that describes how that particular part of the application fits together with the other parts.
NgModules are specific to Angular.
While classes with an `@NgModule` decorator are by convention kept in their own files, they differ from JavaScript modules because they include this metadata.
The `@NgModule` metadata plays an important role in guiding the Angular compilation process that converts the app code you write into highly performant JavaScript code.
The `@NgModule` metadata plays an important role in guiding the Angular compilation process that converts the application code you write into highly performant JavaScript code.
The metadata describes how to compile a component's template and how to create an [injector](guide/glossary#injector "Definition of injector") at runtime.
It identifies the NgModule's [components](guide/glossary#component "Definition of component"), [directives](guide/glossary#directive "Definition of directive"), and [pipes](guide/glossary#pipe "Definition of pipe)"),
and makes some of them public through the `exports` property so that external components can use them.
You can also use an NgModule to add [providers](guide/glossary#provider "Definition of provider") for [services](guide/glossary#service "Definition of a service"), so that the services are available elsewhere in your app.
You can also use an NgModule to add [providers](guide/glossary#provider "Definition of provider") for [services](guide/glossary#service "Definition of a service"), so that the services are available elsewhere in your application.
Rather than defining all member classes in one giant file as a JavaScript module, declare which components, directives, and pipes belong to the NgModule in the `@NgModule.declarations` list.
These classes are called [declarables](guide/glossary#declarable "Definition of a declarable").
@ -56,7 +56,7 @@ For a complete description of the NgModule metadata properties, see [Using the N
## An example that uses both
The root NgModule `AppModule` generated by the [Angular CLI](cli) for a new app project demonstrates how you use both kinds of modules:
The root NgModule `AppModule` generated by the [Angular CLI](cli) for a new application project demonstrates how you use both kinds of modules:
<code-example path="ngmodules/src/app/app.module.1.ts" header="src/app/app.module.ts (default AppModule)"></code-example>
@ -64,7 +64,7 @@ The root NgModule starts with `import` statements to import JavaScript modules.
It then configures the `@NgModule` with the following arrays:
* `declarations`: The components, directives, and pipes that belong to the NgModule.
A new app project's root NgModule has only one component, called `AppComponent`.
A new application project's root NgModule has only one component, called `AppComponent`.
* `imports`: Other NgModules you are using, so that you can use their declarables.
The newly generated root NgModule imports [`BrowserModule`](api/platform-browser/BrowserModule "BrowserModule NgModule") in order to use browser-specific services such as [DOM](https://www.w3.org/TR/DOM-Level-2-Core/introduction.html "Definition of Document Object Model") rendering, sanitization, and location.
@ -72,7 +72,7 @@ It then configures the `@NgModule` with the following arrays:
* `providers`: Providers of services that components in other NgModules can use.
There are no providers in a newly generated root NgModule.
* `bootstrap`: The [entry component](guide/entry-components "Specifying an entry component") that Angular creates and inserts into the `index.html` host web page, thereby bootstrapping the app.
* `bootstrap`: The [entry component](guide/entry-components "Specifying an entry component") that Angular creates and inserts into the `index.html` host web page, thereby bootstrapping the application.
This entry component, `AppComponent`, appears in both the `declarations` and the `bootstrap` arrays.
## Next steps

10
aio/content/guide/ngmodules.md
View File

@ -8,7 +8,7 @@ It identifies the module's own components, directives, and pipes,
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
For an example application showcasing all the techniques that NgModules related pages
cover, see the <live-example></live-example>. For explanations on the individual techniques, visit the relevant NgModule pages under the NgModules
section.
@ -38,17 +38,17 @@ NgModule metadata does the following:
* Imports other modules with the components, directives, and pipes that components in the current module need.
* Provides services that other application components can use.
Every Angular app has at least one module, the root module.
Every Angular application has at least one module, the root module.
You [bootstrap](guide/bootstrapping) that module to launch the application.
The root module is all you need in a simple application with a few components.
As the app grows, you refactor the root module into [feature modules](guide/feature-modules)
The root module is all you need in an application with few components.
As the application grows, you refactor the root module into [feature modules](guide/feature-modules)
that represent collections of related functionality.
You then import these modules into the root module.
## The basic NgModule
The [Angular CLI](cli) generates the following basic `AppModule` when creating a new app.
The [Angular CLI](cli) generates the following basic `AppModule` when creating a new application.
<code-example path="ngmodules/src/app/app.module.1.ts" header="src/app/app.module.ts (default AppModule)">

10
aio/content/guide/providers.md
View File

@ -2,12 +2,12 @@
A provider is an instruction to the [Dependency Injection](/guide/dependency-injection) system on how to obtain a value for a dependency. Most of the time, these dependencies are services that you create and provide.
For the final sample app using the provider that this page describes,
For the final sample application using the provider that this page describes,
see the <live-example></live-example>.
## Providing a service
If you already have an app that was created with the [Angular CLI](cli), you can create a service using the [`ng generate`](cli/generate) CLI command in the root project directory. Replace _User_ with the name of your service.
If you already have an application that was created with the [Angular CLI](cli), you can create a service using the [`ng generate`](cli/generate) CLI command in the root project directory. Replace _User_ with the name of your service.
```sh
ng generate service User
@ -24,7 +24,7 @@ The service itself is a class that the CLI generated and that's decorated with `
## Provider scope
When you add a service provider to the root application injector, it’s available throughout the app. Additionally, these providers are also available to all the classes in the app as long they have the lookup token.
When you add a service provider to the root application injector, it’s available throughout the application. Additionally, these providers are also available to all the classes in the application as long they have the lookup token.
You should always provide your service in the root injector unless there is a case where you want the service to be available only if the consumer imports a particular `@NgModule`.
@ -40,7 +40,7 @@ The example above shows the preferred way to provide a service in a module. This
## Limiting provider scope by lazy loading modules
In the basic CLI-generated app, modules are eagerly loaded which means that they are all loaded when the app launches. Angular uses an injector system to make things available between modules. In an eagerly loaded app, the root application injector makes all of the providers in all of the modules available throughout the app.
In the basic CLI-generated app, modules are eagerly loaded which means that they are all loaded when the application launches. Angular uses an injector system to make things available between modules. In an eagerly loaded app, the root application injector makes all of the providers in all of the modules available throughout the application.
This behavior necessarily changes when you use lazy loading. Lazy loading is when you load modules only when you need them; for example, when routing. They aren’t loaded right away like with eagerly loaded modules. This means that any services listed in their provider arrays aren’t available because the root injector doesn’t know about these modules.
@ -74,7 +74,7 @@ Other components in the same module can’t access it.
## Providing services in modules vs. components
Generally, provide services the whole app needs in the root module and scope services by providing them in lazy loaded modules.
Generally, provide services the whole application needs in the root module and scope services by providing them in lazy loaded modules.
The router works at the root level so if you put providers in a component, even `AppComponent`, lazy loaded modules, which rely on the router, can’t see them.

2
aio/content/guide/sharing-ngmodules.md
View File

@ -2,7 +2,7 @@
Creating shared modules allows you to organize and streamline your code. You can put commonly
used directives, pipes, and components into one module and then import just that module wherever
you need it in other parts of your app.
you need it in other parts of your application.
Consider the following module from an imaginary app:

18
aio/content/guide/singleton-services.md
View File

@ -1,8 +1,8 @@
# Singleton services
A singleton service is a service for which only one instance exists in an app.
A singleton service is a service for which only one instance exists in an application.
For a sample app using the app-wide singleton service that this page describes, see the
For a sample application using the app-wide singleton service that this page describes, see the
<live-example name="ngmodules"></live-example> showcasing all the documented features of NgModules.
## Providing a singleton service
@ -27,7 +27,7 @@ For more detailed information on services, see the [Services](tutorial/toh-pt4)
### NgModule `providers` array
In apps built with Angular versions prior to 6.0, services are registered NgModule `providers` arrays as follows:
In applications built with Angular versions prior to 6.0, services are registered NgModule `providers` arrays as follows:
```ts
@NgModule({
@ -39,7 +39,7 @@ In apps built with Angular versions prior to 6.0, services are registered NgModu
```
If this NgModule were the root `AppModule`, the `UserService` would be a singleton and available
throughout the app. Though you may see it coded this way, using the `providedIn` property of the `@Injectable()` decorator on the service itself is preferable as of Angular 6.0 as it makes your services tree-shakable.
throughout the application. Though you may see it coded this way, using the `providedIn` property of the `@Injectable()` decorator on the service itself is preferable as of Angular 6.0 as it makes your services tree-shakable.
{@a forRoot}
@ -58,7 +58,7 @@ There are multiple ways to prevent this:
<div class="alert is-helpful">
**Note:** There are two example apps where you can see this scenario; the more advanced <live-example noDownload name="ngmodules">NgModules live example</live-example>, which contains `forRoot()` and `forChild()` in the routing modules and the `GreetingModule`, and the simpler <live-example name="lazy-loading-ngmodules" noDownload>Lazy Loading live example</live-example>. For an introductory explanation see the [Lazy Loading Feature Modules](guide/lazy-loading-ngmodules) guide.
**Note:** There are two example applications where you can see this scenario; the more advanced <live-example noDownload name="ngmodules">NgModules live example</live-example>, which contains `forRoot()` and `forChild()` in the routing modules and the `GreetingModule`, and the simpler <live-example name="lazy-loading-ngmodules" noDownload>Lazy Loading live example</live-example>. For an introductory explanation see the [Lazy Loading Feature Modules](guide/lazy-loading-ngmodules) guide.
</div>
@ -85,7 +85,7 @@ If the `RouterModule` didn’t have `forRoot()` then each feature module would i
**Note:** If you have a module which has both providers and declarations,
you _can_ use this
technique to separate them out and you may see this pattern in legacy apps.
technique to separate them out and you may see this pattern in legacy applications.
However, since Angular 6.0, the best practice for providing services is with the
`@Injectable()` `providedIn` property.
@ -109,7 +109,7 @@ This sequence ensures that whatever you add explicitly to
the `AppModule` providers takes precedence over the providers
of imported modules.
The sample app imports `GreetingModule` and uses its `forRoot()` method one time, in `AppModule`. Registering it once like this prevents multiple instances.
The sample application imports `GreetingModule` and uses its `forRoot()` method one time, in `AppModule`. Registering it once like this prevents multiple instances.
You can also add a `forRoot()` method in the `GreetingModule` that configures
the greeting `UserService`.
@ -128,14 +128,14 @@ snippet, other parts of the file are left out. For the complete file, see the <l
<code-example path="ngmodules/src/app/app.module.ts" region="import-for-root" header="src/app/app.module.ts (imports)"></code-example>
The app displays "Miss Marple" as the user instead of the default "Sherlock Holmes".
The application displays "Miss Marple" as the user instead of the default "Sherlock Holmes".
Remember to import `GreetingModule` as a Javascript import at the top of the file and don't add it to more than one `@NgModule` `imports` list.
## Prevent reimport of the `GreetingModule`
Only the root `AppModule` should import the `GreetingModule`. If a
lazy-loaded module imports it too, the app can generate
lazy-loaded module imports it too, the application can generate
[multiple instances](guide/ngmodule-faq#q-why-bad) of a service.
To guard against a lazy loaded module re-importing `GreetingModule`, add the following `GreetingModule` constructor.