mirror of
https://github.com/angular/angular
synced 2026-05-24 09:28:37 +00:00
**Pipes Sample Code** Migrated all sample code in the `examples/pipes` folder. Did not touch the pipes in the ToH or Testing folders. >The existing, complex discussion of the `CurrencyPipe` within `pipes-transform-data.md` cried out for a new `concurrency-formatting.component` example`. **Extracted "pipe precedence" into its own page** The topic had been extracted from `pipe.md` and tacked on to the bottom of the `pipes-overview.md` page. It's an advanced and somewhat obscure topic that doesn't belong in the overview. Rather than throw it away, I created a new `pipe-precedence.md` page and added it to the bottom of the pipes section navigation. I also tried to improve both the guide text and the companion component, `precedence.component`. **How to create a pipe is missing** The readers are told they can create their own pipes in several places throughout the docs. But there are no links and you can't navigate to a page that covers the topic. This is a serious omission! The topic is introduced in the `pipes-custom-data-trans.md` page (extracted verbatim from `pipes.md`). But you can't navigate to this page and their are no links to it. TODO: restore this page and add it to the left-nav. **Change `pipes.md` references to `pipe-overview.md`** The original, kitchen-sink page, `pipes.md`, was disconnected from navigation long ago, in favor of multiple pages such as `pipe-overview.md`. The page is still in the AIO documentation and can be found by searching or by links from 3rd party documenters. Landing on that page hides the left-nav. In this commit, we treat `pipes.md` as deprecated (which it seems to be). Therefore, this commit retargets previous `pipes.md` references to `pipe-overview.md`. >The `change-detection-slow-computations.md` is the exception. It refers to "pure pipes", a subject not covered in the current pipe documentation. That reference is retargeted to `api/core/Pipe#pure`. Certain code files are only referenced in `pipe.md`. They still work and are displayed in the overall pipes code sample as before. Now they are marked with deprecation comments for future treatment or removal. For consistency, certain sections of `pipes.md` were replaced by the contents of the corresponding current pages. PR Close #51333
162 lines
7.3 KiB
Markdown
162 lines
7.3 KiB
Markdown
# Launching your app with a root module
|
|
|
|
## Prerequisites
|
|
|
|
A basic understanding of the following:
|
|
|
|
* [JavaScript Modules vs. NgModules](guide/ngmodule-vs-jsmodule)
|
|
|
|
An NgModule describes how the application parts fit together.
|
|
Every application has at least one Angular module, the *root* module, which must be present for bootstrapping the application on launch.
|
|
By convention and by default, this NgModule is named `AppModule`.
|
|
|
|
When you use the [Angular CLI](cli) command `ng new` to generate an app, the default `AppModule` looks like the following:
|
|
|
|
<code-example format="typescript" language="typescript">
|
|
|
|
/* JavaScript imports */
|
|
import { BrowserModule } from '@angular/platform-browser';
|
|
import { NgModule } from '@angular/core';
|
|
|
|
import { AppComponent } from './app.component';
|
|
|
|
/* the AppModule class with the @NgModule decorator */
|
|
@NgModule({
|
|
declarations: [
|
|
AppComponent
|
|
],
|
|
imports: [
|
|
BrowserModule
|
|
],
|
|
providers: [],
|
|
bootstrap: [AppComponent]
|
|
})
|
|
export class AppModule { }
|
|
|
|
</code-example>
|
|
|
|
After the import statements is a class with the **`@NgModule`** [decorator](guide/glossary#decorator '"Decorator" explained').
|
|
|
|
The `@NgModule` decorator identifies `AppModule` as an `NgModule` class.
|
|
`@NgModule` takes a metadata object that tells Angular how to compile and launch the application.
|
|
|
|
| metadata object | Details |
|
|
|:--- |:--- |
|
|
| declarations | This application's lone component. |
|
|
| imports | Import `BrowserModule` to have browser-specific services such as DOM rendering, sanitization, and location. |
|
|
| providers | The service providers. |
|
|
| bootstrap | The *root* component that Angular creates and inserts into the `index.html` host web page. |
|
|
|
|
The default application created by the Angular CLI only has one component, `AppComponent`, so it is in both the `declarations` and the `bootstrap` arrays.
|
|
|
|
<a id="declarations"></a>
|
|
|
|
## The `declarations` array
|
|
|
|
The module's `declarations` array tells Angular which components belong to that module.
|
|
As you create more components, add them to `declarations`.
|
|
|
|
You must declare every component in exactly one `NgModule` class.
|
|
If you use a component without declaring it, Angular returns an error message.
|
|
|
|
The `declarations` array only takes declarables. Declarables are components, [directives](guide/attribute-directives), and [pipes](guide/pipes-overview).
|
|
All of a module's declarables must be in the `declarations` array.
|
|
Declarables must belong to exactly one module. The compiler emits an error if you try to declare the same class in more than one module.
|
|
|
|
These declared classes are visible within the module but invisible to components in a different module, unless they are exported from this module and the other module imports this one.
|
|
|
|
An example of what goes into a declarations array follows:
|
|
|
|
<code-example format="typescript" language="typescript">
|
|
|
|
declarations: [
|
|
YourComponent,
|
|
YourPipe,
|
|
YourDirective
|
|
],
|
|
|
|
</code-example>
|
|
|
|
A declarable can only belong to one module, so only declare it in one `@NgModule`.
|
|
When you need it elsewhere, import the module that contains the declarable you need.
|
|
|
|
### Using directives with `@NgModule`
|
|
|
|
Use the `declarations` array for directives.
|
|
To use a directive, component, or pipe in a module, you must do a few things:
|
|
|
|
1. Export it from the file where you wrote it.
|
|
1. Import it into the appropriate module.
|
|
1. Declare it in the `@NgModule` `declarations` array.
|
|
|
|
Those three steps look like the following. In the file where you create your directive, export it.
|
|
The following example, named `ItemDirective` is the default directive structure that the CLI generates in its own file, `item.directive.ts`:
|
|
|
|
<code-example header="src/app/item.directive.ts" path="bootstrapping/src/app/item.directive.ts" region="directive"></code-example>
|
|
|
|
The key point here is that you have to export it, so that you can import it elsewhere.
|
|
Next, import it into the `NgModule`, in this example `app.module.ts`, with a JavaScript import statement:
|
|
|
|
<code-example header="src/app/app.module.ts" path="bootstrapping/src/app/app.module.ts" region="directive-import"></code-example>
|
|
|
|
And in the same file, add it to the `@NgModule` `declarations` array:
|
|
|
|
<code-example header="src/app/app.module.ts" path="bootstrapping/src/app/app.module.ts" region="declarations"></code-example>
|
|
|
|
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-overview) and components.
|
|
|
|
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 id="imports"></a>
|
|
|
|
## The `imports` array
|
|
|
|
The module's `imports` array appears exclusively in the `@NgModule` metadata object.
|
|
It tells Angular about other NgModules that this particular module needs to function properly.
|
|
|
|
<code-example header="src/app/app.module.ts (excerpt)" path="bootstrapping/src/app/app.module.ts" region="imports"></code-example>
|
|
|
|
This list of modules are those that export components, directives, or pipes that component templates in this module reference.
|
|
In this case, the component is `AppComponent`, which references components, directives, or pipes in `BrowserModule`, `FormsModule`, or `HttpClientModule`.
|
|
A component template can reference another component, directive, or pipe when the referenced class is declared in this module, or the class was imported from another module.
|
|
|
|
<a id="bootstrap-array"></a>
|
|
|
|
## The `providers` array
|
|
|
|
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).
|
|
|
|
## The `bootstrap` array
|
|
|
|
The application launches by bootstrapping the root `AppModule`, which is also referred to as an `entryComponent`.
|
|
Among other things, the bootstrapping process creates the component\(s\) listed in the `bootstrap` array and inserts each one into the browser DOM.
|
|
|
|
Each bootstrapped component is the base of its own tree of components.
|
|
Inserting a bootstrapped component usually triggers a cascade of component creations that fill out that tree.
|
|
|
|
While you can put more than one component tree on a host web page, most applications have only one component tree and bootstrap a single root component.
|
|
|
|
This one root component is usually called `AppComponent` and is in the root module's `bootstrap` array.
|
|
|
|
In a situation where you want to bootstrap a component based on an API response,
|
|
or you want to mount the `AppComponent` in a different DOM node that doesn't match the component selector, please refer to `ApplicationRef.bootstrap()` documentation.
|
|
|
|
## More about Angular Modules
|
|
|
|
For more on NgModules you're likely to see frequently in applications, see [Frequently Used Modules](guide/frequent-ngmodules).
|
|
|
|
<!-- links -->
|
|
|
|
<!-- external links -->
|
|
|
|
<!-- end links -->
|
|
|
|
@reviewed 2023-08-14
|