docs: remove redundant whitespaces and fix minor typos (#33422)
PR Close #33422
This commit is contained in:
parent
8b5ca670ad
commit
2f6c97e93c
|
@ -144,7 +144,7 @@ describes the JSON format as a collection of TypeScript interfaces.
|
|||
{@a expression-syntax}
|
||||
### Expression syntax limitations
|
||||
|
||||
The AOT collector only understands a subset of JavaScript.
|
||||
The AOT collector only understands a subset of JavaScript.
|
||||
Define metadata objects with the following limited syntax:
|
||||
|
||||
<style>
|
||||
|
|
|
@ -35,7 +35,7 @@ Here's an example of basic metadata for `HeroListComponent`.
|
|||
|
||||
This example shows some of the most useful `@Component` configuration options:
|
||||
|
||||
* `selector`: A CSS selector that tells Angular to create and insert an instance of this component wherever it finds the corresponding tag in template HTML. For example, if an app's HTML contains `<app-hero-list></app-hero-list>`, then
|
||||
* `selector`: A CSS selector that tells Angular to create and insert an instance of this component wherever it finds the corresponding tag in template HTML. For example, if an app's HTML contains `<app-hero-list></app-hero-list>`, then
|
||||
Angular inserts an instance of the `HeroListComponent` view between those tags.
|
||||
|
||||
* `templateUrl`: The module-relative address of this component's HTML template. Alternatively, you can provide the HTML template inline, as the value of the `template` property. This template defines the component's *host view*.
|
||||
|
@ -54,7 +54,7 @@ Views are typically arranged hierarchically, allowing you to modify or show and
|
|||
<figure class="lightbox">
|
||||
<div class="card">
|
||||
<img src="generated/images/guide/architecture/component-tree.png" alt="Component tree" class="left">
|
||||
</div>
|
||||
</div>
|
||||
</figure>
|
||||
|
||||
A view hierarchy can include views from components in the same NgModule, but it also can (and often does) include views from components that are defined in different NgModules.
|
||||
|
|
|
@ -84,7 +84,7 @@ or you can register providers with specific modules or components.
|
|||
You register providers in the metadata of the service (in the `@Injectable()` decorator),
|
||||
or in the `@NgModule()` or `@Component()` metadata
|
||||
|
||||
* By default, the Angular CLI command [`ng generate service`](cli/generate) registers a provider with the root injector for your service by including provider metadata in the `@Injectable()` decorator. The tutorial uses this method to register the provider of HeroService class definition.
|
||||
* By default, the Angular CLI command [`ng generate service`](cli/generate) registers a provider with the root injector for your service by including provider metadata in the `@Injectable()` decorator. The tutorial uses this method to register the provider of HeroService class definition.
|
||||
|
||||
```
|
||||
@Injectable({
|
||||
|
|
|
@ -411,7 +411,7 @@ Proxy log levels are `info` (the default), `debug`, `warn`, `error`, and `silent
|
|||
|
||||
### Proxy multiple entries
|
||||
|
||||
You can proxy multiple entries to the same target by defining the configuration in JavaScript.
|
||||
You can proxy multiple entries to the same target by defining the configuration in JavaScript.
|
||||
|
||||
Set the proxy configuration file to `proxy.conf.js` (instead of `proxy.conf.json`), and specify configuration files as in the following example.
|
||||
|
||||
|
|
|
@ -30,7 +30,7 @@ This object contains a Boolean `success` field and an optional `error` field tha
|
|||
|
||||
Angular provides some builders that are used by the CLI for commands such as `ng build`, `ng test`, and `ng lint`.
|
||||
Default target configurations for these and other built-in CLI builders can be found (and customized) in the "architect" section of the [workspace configuration file](guide/workspace-config), `angular.json`.
|
||||
You can also extend and customize Angular by creating your own builders, which you can run using the [`ng run` CLI command](cli/run).
|
||||
You can also extend and customize Angular by creating your own builders, which you can run using the [`ng run` CLI command](cli/run).
|
||||
|
||||
### Builder project structure
|
||||
|
||||
|
@ -144,7 +144,7 @@ You can see an [example](https://github.com/angular/angular-cli/blob/ba21c855c0c
|
|||
|
||||
In our example, the shell command either finishes or is still executing, so there’s no need for a progress report, but we can report status so that a parent builder that called our builder would know what’s going on.
|
||||
Use the `BuilderContext.reportStatus()` method to generate a status string of any length.
|
||||
(Note that there’s no guarantee that a long string will be shown entirely; it could be cut to fit the UI that displays it.)
|
||||
(Note that there’s no guarantee that a long string will be shown entirely; it could be cut to fit the UI that displays it.)
|
||||
Pass an empty string to remove the status.
|
||||
|
||||
<code-example language="typescript" header="/command/index.ts">
|
||||
|
@ -253,7 +253,7 @@ In the `package.json` file, add a `builders` key that tells the Architect tool w
|
|||
</code-example>
|
||||
|
||||
The official name of our builder is now ` @example/command-runner:command`.
|
||||
The first part of this is the package name (resolved using node resolution), and the second part is the builder name (resolved using the `builders.json` file).
|
||||
The first part of this is the package name (resolved using node resolution), and the second part is the builder name (resolved using the `builders.json` file).
|
||||
|
||||
Using one of our `options` is very straightforward, we did this in the previous section when we accessed `options.command`.
|
||||
|
||||
|
@ -311,7 +311,7 @@ You might also add more alternative configurations to the `build` target, to def
|
|||
|
||||
#### Target strings
|
||||
|
||||
The generic `ng run` CLI command takes as its first argument a target string of the form *project:target[:configuration]*.
|
||||
The generic `ng run` CLI command takes as its first argument a target string of the form *project:target[:configuration]*.
|
||||
|
||||
* *project*: The name of the Angular CLI project that the target is associated with.
|
||||
|
||||
|
|
|
@ -26,8 +26,8 @@ Observables are often compared to promises. Here are some key differences:
|
|||
new Observable((observer) => { subscriber_fn });
|
||||
// initiate execution
|
||||
observable.subscribe(() => {
|
||||
// observer handles notifications
|
||||
});
|
||||
// observer handles notifications
|
||||
});
|
||||
</code-example>
|
||||
|
||||
* Promises execute immediately, and just once. The computation of the result is initiated when the promise is created. There is no way to restart work. All `then` clauses (subscriptions) share the same computation.
|
||||
|
@ -37,8 +37,8 @@ observable.subscribe(() => {
|
|||
new Promise((resolve, reject) => { executer_fn });
|
||||
// handle return value
|
||||
promise.then((value) => {
|
||||
// handle result here
|
||||
});
|
||||
// handle result here
|
||||
});
|
||||
</code-example>
|
||||
|
||||
### Chaining
|
||||
|
@ -80,7 +80,7 @@ obs.subscribe(() => {
|
|||
|
||||
<code-example hideCopy>
|
||||
promise.then(() => {
|
||||
throw Error('my error');
|
||||
throw Error('my error');
|
||||
});
|
||||
</code-example>
|
||||
|
||||
|
@ -314,6 +314,3 @@ An observable produces values over time. An array is created as a static set of
|
|||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
#### Prerequisites
|
||||
|
||||
A basic understanding of the following concepts:
|
||||
A basic understanding of the following concepts:
|
||||
|
||||
* [Introduction to Angular animations](guide/animations)
|
||||
* [Transition and triggers](guide/transition-and-triggers)
|
||||
|
|
|
@ -129,7 +129,7 @@ Detect and act upon changes to input property values with the `ngOnChanges()` me
|
|||
|
||||
You may prefer this approach to the property setter when watching multiple, interacting input properties.
|
||||
|
||||
Learn about `ngOnChanges()` in the [LifeCycle Hooks](guide/lifecycle-hooks) chapter.
|
||||
Learn about `ngOnChanges()` in the [Lifecycle Hooks](guide/lifecycle-hooks) chapter.
|
||||
|
||||
</div>
|
||||
|
||||
|
|
|
@ -47,7 +47,7 @@ You can build, test, and lint the project with CLI commands:
|
|||
ng lint my-lib
|
||||
</code-example>
|
||||
|
||||
Notice that the configured builder for the project is different from the default builder for app projects.
|
||||
Notice that the configured builder for the project is different from the default builder for app projects.
|
||||
This builder, among other things, ensures that the library is always built with the [AoT compiler](guide/aot-compiler), without the need to specify the `--prod` flag.
|
||||
|
||||
To make library code reusable you must define a public API for it. This "user layer" defines what is available to consumers of your library. A user of your library should be able to access public functionality (such as NgModules, service providers and general utility functions) through a single import path.
|
||||
|
@ -181,7 +181,7 @@ For instance, if you clone your git repository and run `npm install`, your edito
|
|||
<div class="alert is-helpful">
|
||||
|
||||
When you import something from a library in an Angular app, Angular looks for a mapping between the library name and a location on disk.
|
||||
When you install a library package, the mapping is in the `node_modules` folder. When you build your own library, it has to find the mapping in your `tsconfig` paths.
|
||||
When you install a library package, the mapping is in the `node_modules` folder. When you build your own library, it has to find the mapping in your `tsconfig` paths.
|
||||
|
||||
Generating a library with the Angular CLI automatically adds its path to the `tsconfig` file.
|
||||
The Angular CLI uses the `tsconfig` paths to tell the build system where to find the library.
|
||||
|
@ -204,7 +204,7 @@ ng build my-lib --watch
|
|||
|
||||
The CLI `build` command uses a different builder and invokes a different build tool for libraries than it does for applications.
|
||||
|
||||
* The build system for apps, `@angular-devkit/build-angular`, is based on `webpack`, and is included in all new Angular CLI projects.
|
||||
* The build system for apps, `@angular-devkit/build-angular`, is based on `webpack`, and is included in all new Angular CLI projects.
|
||||
* The build system for libraries is based on `ng-packagr`. It is only added to your dependencies when you add a library using `ng generate library my-lib`.
|
||||
|
||||
The two build systems support different things, and even where they support the same things, they do those things differently.
|
||||
|
|
|
@ -586,7 +586,7 @@ an interface is not a valid DI token because it is a TypeScript artifact that do
|
|||
Use this abstract class interface to get the strong typing of an interface,
|
||||
and also use it as a provider token in the way you would a normal class.
|
||||
|
||||
A class interface should define *only* the members that its consumers are allowed to call.
|
||||
A class interface should define *only* the members that its consumers are allowed to call.
|
||||
Such a narrowing interface helps decouple the concrete class from its consumers.
|
||||
|
||||
|
||||
|
|
|
@ -233,7 +233,7 @@ A component that could serve as a parent *should* implement the class interface
|
|||
|
||||
|
||||
|
||||
Doing so adds clarity to the code. But it's not technically necessary.
|
||||
Doing so adds clarity to the code. But it's not technically necessary.
|
||||
Although `AlexComponent` has a `name` property, as required by its `Base` class,
|
||||
its class signature doesn't mention `Parent`.
|
||||
|
||||
|
@ -283,4 +283,3 @@ Here's a revised version that defaults to `parent` but also accepts an optional
|
|||
And here's how you could use it with a different parent type.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="beth-providers" header="dependency-injection-in-action/src/app/parent-finder.component.ts"></code-example>
|
||||
|
||||
|
|
|
@ -114,7 +114,7 @@ from the injector of its parent NgModule, or from the `root` injector.
|
|||
|
||||
* Learn more about the [different kinds of providers](guide/dependency-injection-providers).
|
||||
|
||||
* Learn more about how the [injector hierarchy](guide/hierarchical-dependency-injection) works.
|
||||
* Learn more about how the [injector hierarchy](guide/hierarchical-dependency-injection) works.
|
||||
|
||||
</div>
|
||||
|
||||
|
@ -229,7 +229,7 @@ Here is the revised `HeroService` that injects `Logger`, side by side with the p
|
|||
|
||||
The constructor asks for an injected instance of `Logger` and stores it in a private field called `logger`. The `getHeroes()` method logs a message when asked to fetch heroes.
|
||||
|
||||
Notice that the `Logger` service also has the `@Injectable()` decorator, even though it might not need its own dependencies. In fact, the `@Injectable()` decorator is **required for all services**.
|
||||
Notice that the `Logger` service also has the `@Injectable()` decorator, even though it might not need its own dependencies. In fact, the `@Injectable()` decorator is **required for all services**.
|
||||
|
||||
When Angular creates a class whose constructor has parameters, it looks for type and injection metadata about those parameters so that it can inject the correct service.
|
||||
If Angular can't find that parameter information, it throws an error.
|
||||
|
@ -293,7 +293,7 @@ value of `logger` to null.
|
|||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
`@Inject()` and `@Optional()` are _parameter decorators_. They alter the way the DI framework provides a dependency, by annotating the dependency parameter on the constructor of the class that requires the dependency.
|
||||
`@Inject()` and `@Optional()` are _parameter decorators_. They alter the way the DI framework provides a dependency, by annotating the dependency parameter on the constructor of the class that requires the dependency.
|
||||
|
||||
Learn more about parameter decorators in [Hierarchical Dependency Injectors](guide/hierarchical-dependency-injection).
|
||||
|
||||
|
@ -314,5 +314,3 @@ Dive deeper into the capabilities and advanced feature of the Angular DI system
|
|||
* Learn more about [DI tokens and providers](guide/dependency-injection-providers).
|
||||
|
||||
* [Dependency Injection in Action](guide/dependency-injection-in-action) is a cookbook for some of the interesting things you can do with DI.
|
||||
|
||||
|
||||
|
|
|
@ -206,7 +206,7 @@ modified to serve `index.html`:
|
|||
|
||||
``` go
|
||||
package main
|
||||
|
||||
|
||||
import (
|
||||
"net/http"
|
||||
"os"
|
||||
|
@ -457,7 +457,7 @@ Even as JavaScript continues to evolve, with new features being introduced, not
|
|||
|
||||
The code you write in development using TypeScript is compiled and bundled into ES2015, the JavaScript syntax that is compatible with most browsers.
|
||||
All modern browsers support ES2015 and beyond, but in most cases, you still have to account for users accessing your application from a browser that doesn't.
|
||||
When targeting older browsers, [polyfills](guide/browser-support#polyfills) can bridge the gap by providing functionality that doesn't exist in the older versions of JavaScript supported by those browsers.
|
||||
When targeting older browsers, [polyfills](guide/browser-support#polyfills) can bridge the gap by providing functionality that doesn't exist in the older versions of JavaScript supported by those browsers.
|
||||
|
||||
To maximize compatibility, you could ship a single bundle that includes all your compiled code, plus any polyfills that may be needed.
|
||||
Users with modern browsers, however, shouldn't have to pay the price of increased bundle size that comes with polyfills they don't need.
|
||||
|
|
|
@ -37,7 +37,7 @@ Angular docs are written in Markdown, with custom extensions for this site. Corr
|
|||
|
||||
* **Angular coding style:** Coding style for example apps and code snippets.
|
||||
Code examples are encouraged for demonstrating how to apply the concepts and features discussed.
|
||||
Angular has a custom framework that enables authors to include code snippets directly from example apps that are automatically tested as part of doc builds.
|
||||
Angular has a custom framework that enables authors to include code snippets directly from example apps that are automatically tested as part of doc builds.
|
||||
To contribute example code, you must understand Angular itself and the custom framework for Angular doc examples.
|
||||
|
||||
For each aspect of style, the following table explains where to find the primary guidelines and what this Angular Documentation Style Guide offers.
|
||||
|
|
|
@ -142,7 +142,7 @@ Notice this component can present any type of question in your model.
|
|||
You only have two types of questions at this point but you can imagine many more.
|
||||
The `ngSwitch` determines which type of question to display.
|
||||
|
||||
In both components you're relying on Angular's **formGroup** to connect the template HTML to the
|
||||
In both components you're relying on Angular's **formGroup** to connect the template HTML to the
|
||||
underlying control objects, populated from the question model with display and validation rules.
|
||||
|
||||
`formControlName` and `formGroup` are directives defined in
|
||||
|
|
|
@ -40,7 +40,7 @@ After you register your configured class with the browser's custom-element regis
|
|||
<my-popup message="Use Angular!"></my-popup>
|
||||
```
|
||||
|
||||
When your custom element is placed on a page, the browser creates an instance of the registered class and adds it to the DOM. The content is provided by the component's template, which uses Angular template syntax, and is rendered using the component and DOM data. Input properties in the component correspond to input attributes for the element.
|
||||
When your custom element is placed on a page, the browser creates an instance of the registered class and adds it to the DOM. The content is provided by the component's template, which uses Angular template syntax, and is rendered using the component and DOM data. Input properties in the component correspond to input attributes for the element.
|
||||
|
||||
<figure class="lightbox">
|
||||
<div class="card">
|
||||
|
|
|
@ -4,7 +4,7 @@ An entry component is any component that Angular loads imperatively, (which mean
|
|||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
To contrast the two types of components, there are components which are included in the template, which are declarative. Additionally, there are components which you load imperatively; that is, entry components.
|
||||
To contrast the two types of components, there are components which are included in the template, which are declarative. Additionally, there are components which you load imperatively; that is, entry components.
|
||||
|
||||
</div>
|
||||
|
||||
|
|
|
@ -58,12 +58,12 @@ This initial root-level application is the *default app* for CLI commands (unles
|
|||
|
||||
</div>
|
||||
|
||||
For a single-application workspace, the `src/` subfolder of the workspace contains the source files (application logic, data, and assets) for the root application.
|
||||
For a single-application workspace, the `src/` subfolder of the workspace contains the source files (application logic, data, and assets) for the root application.
|
||||
For a multi-project workspace, additional projects in the `projects/` folder contain a `project-name/src/` subfolder with the same structure.
|
||||
|
||||
### Application source files
|
||||
|
||||
Files at the top level of `src/` support testing and running your application. Subfolders contain the application source and application-specific configuration.
|
||||
Files at the top level of `src/` support testing and running your application. Subfolders contain the application source and application-specific configuration.
|
||||
|
||||
| APP SUPPORT FILES | PURPOSE |
|
||||
| :--------------------- | :------------------------------------------|
|
||||
|
@ -72,7 +72,7 @@ Files at the top level of `src/` support testing and running your application.
|
|||
| `environments/` | Contains build configuration options for particular target environments. By default there is an unnamed standard development environment and a production ("prod") environment. You can define additional target environment configurations. |
|
||||
| `favicon.ico` | An icon to use for this application in the bookmark bar. |
|
||||
| `index.html` | The main HTML page that is served when someone visits your site. The CLI automatically adds all JavaScript and CSS files when building your app, so you typically don't need to add any `<script>` or` <link>` tags here manually. |
|
||||
| `main.ts` | The main entry point for your application. Compiles the application with the [JIT compiler](https://angular.io/guide/glossary#jit) and bootstraps the application's root module (AppModule) to run in the browser. You can also use the [AOT compiler](https://angular.io/guide/aot-compiler) without changing any code by appending the `--aot` flag to the CLI `build` and `serve` commands. |
|
||||
| `main.ts` | The main entry point for your application. Compiles the application with the [JIT compiler](https://angular.io/guide/glossary#jit) and bootstraps the application's root module (AppModule) to run in the browser. You can also use the [AOT compiler](https://angular.io/guide/aot-compiler) without changing any code by appending the `--aot` flag to the CLI `build` and `serve` commands. |
|
||||
| `polyfills.ts` | Provides polyfill scripts for browser support. |
|
||||
| `styles.sass` | Lists CSS files that supply styles for a project. The extension reflects the style preprocessor you have configured for the project. |
|
||||
| `test.ts` | The main entry point for your unit tests, with some Angular-specific configuration. You don't typically need to edit this file. |
|
||||
|
@ -84,7 +84,7 @@ Angular components, templates, and styles go here.
|
|||
|
||||
| `src/app/` FILES | PURPOSE |
|
||||
| :-------------------------- | :------------------------------------------|
|
||||
| `app/app.component.ts` | Defines the logic for the app's root component, named `AppComponent`. The view associated with this root component becomes the root of the [view hierarchy](guide/glossary#view-hierarchy) as you add components and services to your application. |
|
||||
| `app/app.component.ts` | Defines the logic for the app's root component, named `AppComponent`. The view associated with this root component becomes the root of the [view hierarchy](guide/glossary#view-hierarchy) as you add components and services to your application. |
|
||||
| `app/app.component.html` | Defines the HTML template associated with the root `AppComponent`. |
|
||||
| `app/app.component.css` | Defines the base CSS stylesheet for the root `AppComponent`. |
|
||||
| `app/app.component.spec.ts` | Defines a unit test for the root `AppComponent`. |
|
||||
|
|
|
@ -1,8 +1,8 @@
|
|||
# Introduction to forms in Angular
|
||||
|
||||
Handling user input with forms is the cornerstone of many common applications. Applications use forms to enable users to log in, to update a profile, to enter sensitive information, and to perform many other data-entry tasks.
|
||||
Handling user input with forms is the cornerstone of many common applications. Applications use forms to enable users to log in, to update a profile, to enter sensitive information, and to perform many other data-entry tasks.
|
||||
|
||||
Angular provides two different approaches to handling user input through forms: reactive and template-driven. Both capture user input events from the view, validate the user input, create a form model and data model to update, and provide a way to track changes.
|
||||
Angular provides two different approaches to handling user input through forms: reactive and template-driven. Both capture user input events from the view, validate the user input, create a form model and data model to update, and provide a way to track changes.
|
||||
|
||||
Reactive and template-driven forms process and manage form data differently. Each offers different advantages.
|
||||
|
||||
|
@ -39,7 +39,7 @@ The table below summarizes the key differences between reactive and template-dri
|
|||
|
||||
## Common foundation
|
||||
|
||||
Both reactive and template-driven forms share underlying building blocks.
|
||||
Both reactive and template-driven forms share underlying building blocks.
|
||||
|
||||
|
||||
* `FormControl` tracks the value and validation status of an individual form control.
|
||||
|
@ -73,7 +73,7 @@ The source of truth provides the value and status of the form element at a given
|
|||
</div>
|
||||
</figure>
|
||||
|
||||
With reactive forms, the form model is explicitly defined in the component class. The reactive form directive (in this case, `FormControlDirective`) then links the existing `FormControl` instance to a specific form element in the view using a value accessor (`ControlValueAccessor` instance).
|
||||
With reactive forms, the form model is explicitly defined in the component class. The reactive form directive (in this case, `FormControlDirective`) then links the existing `FormControl` instance to a specific form element in the view using a value accessor (`ControlValueAccessor` instance).
|
||||
|
||||
### Setup in template-driven forms
|
||||
|
||||
|
@ -90,7 +90,7 @@ In template-driven forms, the source of truth is the template.
|
|||
</div>
|
||||
</figure>
|
||||
|
||||
The abstraction of the form model promotes simplicity over structure. The template-driven form directive `NgModel` is responsible for creating and managing the `FormControl` instance for a given form element. It's less explicit, but you no longer have direct control over the form model.
|
||||
The abstraction of the form model promotes simplicity over structure. The template-driven form directive `NgModel` is responsible for creating and managing the `FormControl` instance for a given form element. It's less explicit, but you no longer have direct control over the form model.
|
||||
|
||||
{@a data-flow-in-forms}
|
||||
|
||||
|
@ -147,8 +147,8 @@ The steps below outline the data flow from view to model when the input value ch
|
|||
1. The `FormControl` instance emits the new value through the `valueChanges` observable.
|
||||
1. Any subscribers to the `valueChanges` observable receive the new value.
|
||||
1. The control value accessor also calls the `NgModel.viewToModelUpdate()` method which emits an `ngModelChange` event.
|
||||
1. Because the component template uses two-way data binding for the `favoriteColor` property, the `favoriteColor` property in the component
|
||||
is updated to the value emitted by the `ngModelChange` event (*Blue*).
|
||||
1. Because the component template uses two-way data binding for the `favoriteColor` property, the `favoriteColor` property in the component
|
||||
is updated to the value emitted by the `ngModelChange` event (*Blue*).
|
||||
|
||||
<figure class="lightbox">
|
||||
<div class="card">
|
||||
|
@ -177,7 +177,7 @@ Validation is an integral part of managing any set of forms. Whether you're chec
|
|||
|
||||
For more information, see [Form Validation](guide/form-validation).
|
||||
|
||||
## Testing
|
||||
## Testing
|
||||
|
||||
Testing plays a large part in complex applications and a simpler testing strategy is useful when validating that your forms function correctly. Reactive forms and template-driven forms have different levels of reliance on rendering the UI to perform assertions based on form control and form field changes. The following examples demonstrate the process of testing forms with reactive and template-driven forms.
|
||||
|
||||
|
@ -249,7 +249,7 @@ The change tracking method plays a role in the efficiency of your application.
|
|||
|
||||
* **Template-driven** forms rely on mutability with two-way data binding to update the data model in the component as changes are made in the template. Because there are no unique changes to track on the data model when using two-way data binding, change detection is less efficient at determining when updates are required.
|
||||
|
||||
The difference is demonstrated in the examples above using the **favorite color** input element.
|
||||
The difference is demonstrated in the examples above using the **favorite color** input element.
|
||||
|
||||
|
||||
* With reactive forms, the **`FormControl` instance** always returns a new value when the control's value is updated.
|
||||
|
@ -267,7 +267,7 @@ If forms are a central part of your application, scalability is very important.
|
|||
|
||||
## Final thoughts
|
||||
|
||||
Choosing a strategy begins with understanding the strengths and weaknesses of the options presented. Low-level API and form model access, predictability, mutability, straightforward validation and testing strategies, and scalability are all important considerations in choosing the infrastructure you use to build your forms in Angular. Template-driven forms are similar to patterns in AngularJS, but they have limitations given the criteria of many modern, large-scale Angular apps. Reactive forms minimize these limitations. Reactive forms integrate with reactive patterns already present in other areas of the Angular architecture, and complement those requirements well.
|
||||
Choosing a strategy begins with understanding the strengths and weaknesses of the options presented. Low-level API and form model access, predictability, mutability, straightforward validation and testing strategies, and scalability are all important considerations in choosing the infrastructure you use to build your forms in Angular. Template-driven forms are similar to patterns in AngularJS, but they have limitations given the criteria of many modern, large-scale Angular apps. Reactive forms minimize these limitations. Reactive forms integrate with reactive patterns already present in other areas of the Angular architecture, and complement those requirements well.
|
||||
|
||||
## Next steps
|
||||
|
||||
|
@ -283,4 +283,3 @@ To learn more about template-driven forms, see the following guides:
|
|||
|
||||
* [Template-driven Forms](guide/forms#template-driven-forms)
|
||||
* [Form Validation](guide/form-validation#template-driven-validation)
|
||||
|
||||
|
|
|
@ -350,7 +350,7 @@ To learn more, see [Browser Support](guide/browser-support).
|
|||
## element
|
||||
|
||||
Angular defines an `ElementRef` class to wrap render-specific native UI elements.
|
||||
In most cases, this allows you to use Angular templates and data binding to access DOM elements
|
||||
In most cases, this allows you to use Angular templates and data binding to access DOM elements
|
||||
without reference to the native element.
|
||||
|
||||
The documentation generally refers to *elements* (`ElementRef` instances), as distinct from *DOM elements*
|
||||
|
@ -938,7 +938,7 @@ View hierarchies can be loaded and unloaded dynamically as the user navigates th
|
|||
|
||||
## view hierarchy
|
||||
|
||||
A tree of related views that can be acted on as a unit. The root view is a component's *host view*. A host view can be the root of a tree of *embedded views*, collected in a *view container* (`ViewContainerRef`) attached to an anchor element in the hosting component. The view hierarchy is a key part of Angular change detection.
|
||||
A tree of related views that can be acted on as a unit. The root view is a component's *host view*. A host view can be the root of a tree of *embedded views*, collected in a *view container* (`ViewContainerRef`) attached to an anchor element in the hosting component. The view hierarchy is a key part of Angular change detection.
|
||||
|
||||
The view hierarchy doesn't imply a component hierarchy. Views that are embedded in the context of a particular hierarchy can be host views of other components. Those components can be in the same NgModule as the hosting component, or belong to other NgModules.
|
||||
|
||||
|
|
|
@ -366,7 +366,7 @@ templates in separate files. For the purposes of understanding
|
|||
how the injection system works, it is useful to look at them
|
||||
from the point of view of a combined logical tree. The term
|
||||
logical distinguishes it from the render tree (your application
|
||||
DOM tree). To mark the locations of where the component
|
||||
DOM tree). To mark the locations of where the component
|
||||
templates are located, this guide uses the `<#VIEW>`
|
||||
pseudo element, which doesn't actually exist in the render tree
|
||||
and is present for mental model purposes only.
|
||||
|
@ -517,7 +517,7 @@ In the logical tree, this would be represented as follows:
|
|||
</app-root>
|
||||
```
|
||||
|
||||
When `<app-root>` requests the `FlowerService`, it is the injector's job
|
||||
When `<app-root>` requests the `FlowerService`, it is the injector's job
|
||||
to resolve the `FlowerService` token. The resolution of the token happens
|
||||
in two phases:
|
||||
|
||||
|
|
|
@ -816,7 +816,7 @@ import {HttpParams} from "@angular/common/http";
|
|||
If there is a search term, the code constructs an options object with an HTML URL-encoded search parameter.
|
||||
If the term were "foo", the GET request URL would be `api/heroes?name=foo`.
|
||||
|
||||
The `HttpParams` are immutable so you'll have to save the returned value of the `.set()` method in order to update the options.
|
||||
The `HttpParams` are immutable so you'll have to save the returned value of the `.set()` method in order to update the options.
|
||||
|
||||
#### Use `fromString` to create HttpParams
|
||||
|
||||
|
@ -988,7 +988,7 @@ use `HttpClientXsrfModule.withOptions()` to override the defaults.
|
|||
## Testing HTTP requests
|
||||
|
||||
As for any external dependency, you must mock the HTTP backend so your tests can simulate interaction with a remote server.
|
||||
The `@angular/common/http/testing` library makes it straightforward to set up such mocking .
|
||||
The `@angular/common/http/testing` library makes it straightforward to set up such mocking.
|
||||
|
||||
Angular's HTTP testing library is designed for a pattern of testing in which the app executes code and makes requests first.
|
||||
The test then expects that certain requests have or have not been made,
|
||||
|
|
|
@ -27,7 +27,7 @@ Below are a few breaking changes that are more likely than others to be visible
|
|||
|
||||
- All classes that use Angular DI must have an Angular decorator like `@Directive()` or `@Injectable` (previously, undecorated classes were allowed if an ancestor class or subclass had a decorator).
|
||||
|
||||
- Unbound inputs for directives (e.g. name in `<my-comp name="">`) are now set upon creation of the view, before change detection runs (previously, all inputs were set during change detection).
|
||||
- Unbound inputs for directives (e.g. name in `<my-comp name="">`) are now set upon creation of the view, before change detection runs (previously, all inputs were set during change detection).
|
||||
|
||||
|
||||
{@a less-common-changes}
|
||||
|
|
|
@ -82,5 +82,4 @@ However, as noted above, classes that already have another class decorator like
|
|||
|
||||
## Should I update my library?
|
||||
|
||||
Yes, if your library has any tokens that are meant to be injected, they should be updated with the `@Injectable()` decorator. In a future version of Angular, a missing `@Injectable()` decorator will always throw an error.
|
||||
|
||||
Yes, if your library has any tokens that are meant to be injected, they should be updated with the `@Injectable()` decorator. In a future version of Angular, a missing `@Injectable()` decorator will always throw an error.
|
||||
|
|
|
@ -6,7 +6,7 @@ The `Renderer` class has been marked as deprecated since Angular version 4. This
|
|||
|
||||
## Why should I migrate to Renderer2?
|
||||
|
||||
The deprecated `Renderer` class has been removed in version 9 of Angular, so it's necessary to migrate to a supported API. Using `Renderer2` is the recommended strategy because it supports a similar set of functionality to `Renderer`. The API surface is quite large (with 19 methods), but the schematic should simplify this process for your applications.
|
||||
The deprecated `Renderer` class has been removed in version 9 of Angular, so it's necessary to migrate to a supported API. Using `Renderer2` is the recommended strategy because it supports a similar set of functionality to `Renderer`. The API surface is quite large (with 19 methods), but the schematic should simplify this process for your applications.
|
||||
|
||||
## Is there action required on my end?
|
||||
|
||||
|
|
|
@ -4,14 +4,14 @@ The Angular Framework, Angular CLI, and components used by Angular applications
|
|||
|
||||
You can download and install these npm packages by using the [npm CLI client](https://docs.npmjs.com/cli/install), which is installed with and runs as a [Node.js®](https://nodejs.org "Nodejs.org") application. By default, the Angular CLI uses the npm client.
|
||||
|
||||
Alternatively, you can use the [yarn client](https://yarnpkg.com/) for downloading and installing npm packages.
|
||||
Alternatively, you can use the [yarn client](https://yarnpkg.com/) for downloading and installing npm packages.
|
||||
|
||||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
See [Local Environment Setup](guide/setup-local "Setting up for Local Development") for information about the required versions and installation of `Node.js` and `npm`.
|
||||
|
||||
If you already have projects running on your machine that use other versions of Node.js and npm, consider using [nvm](https://github.com/creationix/nvm) to manage the multiple versions of Node.js and npm.
|
||||
If you already have projects running on your machine that use other versions of Node.js and npm, consider using [nvm](https://github.com/creationix/nvm) to manage the multiple versions of Node.js and npm.
|
||||
|
||||
</div>
|
||||
|
||||
|
@ -20,12 +20,12 @@ If you already have projects running on your machine that use other versions of
|
|||
|
||||
Both `npm` and `yarn` install the packages that are identified in a [`package.json`](https://docs.npmjs.com/files/package.json) file.
|
||||
|
||||
The CLI command `ng new` creates a `package.json` file when it creates the new workspace.
|
||||
This `package.json` is used by all projects in the workspace, including the initial app project that is created by the CLI when it creates the workspace.
|
||||
The CLI command `ng new` creates a `package.json` file when it creates the new workspace.
|
||||
This `package.json` is used by all projects in the workspace, including the initial app project that is created by the CLI when it creates the workspace.
|
||||
|
||||
Initially, this `package.json` includes _a starter set of packages_, some of which are required by Angular and others that support common application scenarios.
|
||||
You add packages to `package.json` as your application evolves.
|
||||
You may even remove some.
|
||||
You add packages to `package.json` as your application evolves.
|
||||
You may even remove some.
|
||||
|
||||
The `package.json` is organized into two groups of packages:
|
||||
|
||||
|
@ -35,14 +35,14 @@ The `package.json` is organized into two groups of packages:
|
|||
<div class="alert is-helpful">
|
||||
|
||||
**Library developers:** By default, the CLI command [`ng generate library`](cli/generate) creates a `package.json` for the new library. That `package.json` is used when publishing the library to npm.
|
||||
For more information, see the CLI wiki page [Library Support](https://github.com/angular/angular-cli/wiki/stories-create-library).
|
||||
For more information, see the CLI wiki page [Library Support](https://github.com/angular/angular-cli/wiki/stories-create-library).
|
||||
</div>
|
||||
|
||||
|
||||
{@a dependencies}
|
||||
## Dependencies
|
||||
|
||||
The packages listed in the `dependencies` section of `package.json` are essential to *running* applications.
|
||||
The packages listed in the `dependencies` section of `package.json` are essential to *running* applications.
|
||||
|
||||
The `dependencies` section of `package.json` contains:
|
||||
|
||||
|
@ -58,7 +58,7 @@ To add a new dependency, use the [`ng add`](cli/add) command.
|
|||
### Angular packages
|
||||
|
||||
The following Angular packages are included as dependencies in the default `package.json` file for a new Angular workspace.
|
||||
For a complete list of Angular packages, see the [API reference](http://angular.io/api?type=package).
|
||||
For a complete list of Angular packages, see the [API reference](http://angular.io/api?type=package).
|
||||
|
||||
Package name | Description
|
||||
---------------------------------------- | --------------------------------------------------
|
||||
|
@ -75,13 +75,13 @@ Package name | Description
|
|||
{@a support-packages}
|
||||
### Support packages
|
||||
|
||||
The following support packages are included as dependencies in the default `package.json` file for a new Angular workspace.
|
||||
The following support packages are included as dependencies in the default `package.json` file for a new Angular workspace.
|
||||
|
||||
|
||||
Package name | Description
|
||||
---------------------------------------- | --------------------------------------------------
|
||||
[**rxjs**](https://github.com/ReactiveX/rxjs) | Many Angular APIs return [_observables_](guide/glossary#observable). RxJS is an implementation of the proposed [Observables specification](https://github.com/tc39/proposal-observable) currently before the [TC39](https://www.ecma-international.org/memento/tc39-m.htm) committee, which determines standards for the JavaScript language.
|
||||
[**zone.js**](https://github.com/angular/zone.js) | Angular relies on zone.js to run Angular's change detection processes when native JavaScript operations raise events. Zone.js is an implementation of a [specification](https://gist.github.com/mhevery/63fdcdf7c65886051d55) currently before the [TC39](http://www.ecma-international.org/memento/TC39.htm) committee that determines standards for the JavaScript language.
|
||||
[**zone.js**](https://github.com/angular/zone.js) | Angular relies on zone.js to run Angular's change detection processes when native JavaScript operations raise events. Zone.js is an implementation of a [specification](https://gist.github.com/mhevery/63fdcdf7c65886051d55) currently before the [TC39](http://www.ecma-international.org/memento/TC39.htm) committee that determines standards for the JavaScript language.
|
||||
|
||||
|
||||
{@a polyfills}
|
||||
|
@ -90,10 +90,10 @@ Package name | Description
|
|||
Many browsers lack native support for some features in the latest HTML standards,
|
||||
features that Angular requires.
|
||||
[_Polyfills_](https://en.wikipedia.org/wiki/Polyfill_(programming)) can emulate the missing features.
|
||||
The [Browser Support](guide/browser-support) guide explains which browsers need polyfills and
|
||||
The [Browser Support](guide/browser-support) guide explains which browsers need polyfills and
|
||||
how you can add them.
|
||||
|
||||
The `package.json` for a new Angular workspace installs the [core-js](https://github.com/zloirock/core-js) package,
|
||||
The `package.json` for a new Angular workspace installs the [core-js](https://github.com/zloirock/core-js) package,
|
||||
which polyfills missing features for several popular browser.
|
||||
|
||||
|
||||
|
@ -113,7 +113,7 @@ To add a new `devDependency`, use either one of the following commands:
|
|||
yarn add --dev <package-name>
|
||||
</code-example>
|
||||
|
||||
The following `devDependencies` are provided in the default `package.json` file for a new Angular workspace.
|
||||
The following `devDependencies` are provided in the default `package.json` file for a new Angular workspace.
|
||||
|
||||
|
||||
Package name | Description
|
||||
|
@ -134,7 +134,7 @@ Package name | Description
|
|||
|
||||
## Related information
|
||||
|
||||
For information about how the Angular CLI handles packages see the following guides:
|
||||
|
||||
For information about how the Angular CLI handles packages see the following guides:
|
||||
|
||||
* [Building and serving](guide/build) describes how packages come together to create a development build.
|
||||
* [Deployment](guide/deployment) describes how packages come together to create a production build.
|
||||
|
|
|
@ -13,7 +13,7 @@ Because of these advantages, observables are used extensively within Angular, an
|
|||
|
||||
As a publisher, you create an `Observable` instance that defines a *subscriber* function. This is the function that is executed when a consumer calls the `subscribe()` method. The subscriber function defines how to obtain or generate values or messages to be published.
|
||||
|
||||
To execute the observable you have created and begin receiving notifications, you call its `subscribe()` method, passing an *observer*. This is a JavaScript object that defines the handlers for the notifications you receive. The `subscribe()` call returns a `Subscription` object that has an `unsubscribe()` method, which you call to stop receiving notifications.
|
||||
To execute the observable you have created and begin receiving notifications, you call its `subscribe()` method, passing an *observer*. This is a JavaScript object that defines the handlers for the notifications you receive. The `subscribe()` call returns a `Subscription` object that has an `unsubscribe()` method, which you call to stop receiving notifications.
|
||||
|
||||
Here's an example that demonstrates the basic usage model by showing how an observable could be used to provide geolocation updates.
|
||||
|
||||
|
@ -77,13 +77,13 @@ Now you can use this function to create an observable that publishes keydown eve
|
|||
|
||||
## Multicasting
|
||||
|
||||
A typical observable creates a new, independent execution for each subscribed observer. When an observer subscribes, the observable wires up an event handler and delivers values to that observer. When a second observer subscribes, the observable then wires up a new event handler and delivers values to that second observer in a separate execution.
|
||||
A typical observable creates a new, independent execution for each subscribed observer. When an observer subscribes, the observable wires up an event handler and delivers values to that observer. When a second observer subscribes, the observable then wires up a new event handler and delivers values to that second observer in a separate execution.
|
||||
|
||||
Sometimes, instead of starting an independent execution for each subscriber, you want each subscription to get the same values—even if values have already started emitting. This might be the case with something like an observable of clicks on the document object.
|
||||
|
||||
*Multicasting* is the practice of broadcasting to a list of multiple subscribers in a single execution. With a multicasting observable, you don't register multiple listeners on the document, but instead re-use the first listener and send values out to each subscriber.
|
||||
|
||||
When creating an observable you should determine how you want that observable to be used and whether or not you want to multicast its values.
|
||||
When creating an observable you should determine how you want that observable to be used and whether or not you want to multicast its values.
|
||||
|
||||
Let’s look at an example that counts from 1 to 3, with a one-second delay after each number emitted.
|
||||
|
||||
|
@ -103,7 +103,7 @@ Notice that if you subscribe twice, there will be two separate streams, each emi
|
|||
|
||||
## Error handling
|
||||
|
||||
Because observables produce values asynchronously, try/catch will not effectively catch errors. Instead, you handle errors by specifying an `error` callback on the observer. Producing an error also causes the observable to clean up subscriptions and stop producing values. An observable can either produce values (calling the `next` callback), or it can complete, calling either the `complete` or `error` callback.
|
||||
Because observables produce values asynchronously, try/catch will not effectively catch errors. Instead, you handle errors by specifying an `error` callback on the observer. Producing an error also causes the observable to clean up subscriptions and stop producing values. An observable can either produce values (calling the `next` callback), or it can complete, calling either the `complete` or `error` callback.
|
||||
|
||||
<code-example>
|
||||
myObservable.subscribe({
|
||||
|
|
|
@ -300,7 +300,7 @@ Notice how a hero is added:
|
|||
|
||||
|
||||
|
||||
You add the hero into the `heroes` array. The reference to the array hasn't changed.
|
||||
You add the hero into the `heroes` array. The reference to the array hasn't changed.
|
||||
It's the same array. That's all Angular cares about. From its perspective, *same array, no change, no display update*.
|
||||
|
||||
To fix that, create an array with the new hero appended and assign that to `heroes`.
|
||||
|
|
|
@ -392,7 +392,7 @@ The aliases control in the form group instance is now populated with a single co
|
|||
|
||||
A getter provides easy access to the aliases in the form array instance compared to repeating the `profileForm.get()` method to get each instance. The form array instance represents an undefined number of controls in an array. It's convenient to access a control through a getter, and this approach is easy to repeat for additional controls.
|
||||
|
||||
Use the getter syntax to create an `aliases` class property to retrieve the alias's form array control from the parent form group.
|
||||
Use the getter syntax to create an `aliases` class property to retrieve the alias's form array control from the parent form group.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.ts" region="aliases-getter" header="src/app/profile-editor/profile-editor.component.ts (aliases getter)">
|
||||
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
#### Prerequisites
|
||||
|
||||
A basic understanding of the following concepts:
|
||||
A basic understanding of the following concepts:
|
||||
|
||||
* [Introduction to Angular animations](guide/animations)
|
||||
* [Transition and triggers](guide/transition-and-triggers)
|
||||
|
|
|
@ -65,7 +65,7 @@ The `<router-outlet>` container has an attribute directive that contains data ab
|
|||
|
||||
<code-example path="animations/src/app/app.component.html" header="src/app/app.component.html" region="route-animations-outlet"></code-example>
|
||||
|
||||
`AppComponent` defines a method that can detect when a view changes. The method assigns an animation state value to the animation trigger (`@routeAnimation`) based on the route configuration `data` property value. Here's an example of an `AppComponent` method that detects when a route change happens.
|
||||
`AppComponent` defines a method that can detect when a view changes. The method assigns an animation state value to the animation trigger (`@routeAnimation`) based on the route configuration `data` property value. Here's an example of an `AppComponent` method that detects when a route change happens.
|
||||
|
||||
<code-example path="animations/src/app/app.component.ts" header="src/app/app.component.ts" region="prepare-router-outlet" language="typescript"></code-example>
|
||||
|
||||
|
|
|
@ -1278,7 +1278,7 @@ The **Routing Module** has several characteristics:
|
|||
|
||||
The sample routing application does not include routing by default.
|
||||
When you use the [Angular CLI](cli) to create a project that will use routing, set the `--routing` option for the project or app, and for each NgModule.
|
||||
When you create or initialize a new project (using the CLI [`ng new`](cli/new) command) or a new app (using the [`ng generate app`](cli/generate) command), specify the `--routing` option. This tells the CLI to include the `@angular/router` npm package and create a file named `app-routing.module.ts`.
|
||||
When you create or initialize a new project (using the CLI [`ng new`](cli/new) command) or a new app (using the [`ng generate app`](cli/generate) command), specify the `--routing` option. This tells the CLI to include the `@angular/router` npm package and create a file named `app-routing.module.ts`.
|
||||
You can then use routing in any NgModule that you add to the project or app.
|
||||
|
||||
For example, the following command generates an NgModule that can use routing.
|
||||
|
@ -3650,7 +3650,7 @@ The `CrisisDetailResolverService` doesn't inherit from a base class.
|
|||
The router looks for that method and calls it if found.
|
||||
|
||||
1. Rely on the router to call the resolver.
|
||||
Don't worry about all the ways that the user could navigate away.
|
||||
Don't worry about all the ways that the user could navigate away.
|
||||
That's the router's job. Write this class and let the router take it from there.
|
||||
|
||||
The relevant *Crisis Center* code for this milestone follows.
|
||||
|
@ -3885,7 +3885,7 @@ and remove the `AdminModule` from the NgModule's `imports` array.
|
|||
|
||||
You're already protecting the `AdminModule` with a `CanActivate` guard that prevents unauthorized users from
|
||||
accessing the admin feature area.
|
||||
It redirects to the login page if the user is not authorized.
|
||||
It redirects to the login page if the user is not authorized.
|
||||
|
||||
But the router is still loading the `AdminModule` even if the user can't visit any of its components.
|
||||
Ideally, you'd only load the `AdminModule` if the user is logged in.
|
||||
|
@ -4309,7 +4309,7 @@ Here's the *Crisis Center* URL in this "HTML5 pushState" style:
|
|||
Older browsers send page requests to the server when the location URL changes
|
||||
_unless_ the change occurs after a "#" (called the "hash").
|
||||
Routers can take advantage of this exception by composing in-application route
|
||||
URLs with hashes. Here's a "hash URL" that routes to the *Crisis Center*.
|
||||
URLs with hashes. Here's a "hash URL" that routes to the *Crisis Center*.
|
||||
|
||||
|
||||
<code-example format="nocode">
|
||||
|
|
|
@ -349,7 +349,7 @@ Each schematic is created with a name, description, and factory function.
|
|||
* The `factory` property points to the generated entry function. In this example, you invoke the `hello-world` schematic by calling the `helloWorld()` factory function.
|
||||
* The optional `schema` property points to a JSON schema file that defines the command-line options available to the schematic.
|
||||
* The optional `aliases` array specifies one or more strings that can be used to invoke the schematic.
|
||||
For example, the schematic for the Angular CLI “generate” command has an alias “g”, allowing you to use the command `ng g`.
|
||||
For example, the schematic for the Angular CLI “generate” command has an alias “g”, allowing you to use the command `ng g`.
|
||||
|
||||
### Named schematics
|
||||
|
||||
|
|
|
@ -76,7 +76,7 @@ To tell the library how to build the schematics, add a `tsconfig.schematics.json
|
|||
|
||||
* The `rootDir` specifies that your `schematics/` folder contains the input files to be compiled.
|
||||
|
||||
* The `outDir` maps to the library's output folder. By default, this is the `dist/my-lib` folder at the root of your workspace.
|
||||
* The `outDir` maps to the library's output folder. By default, this is the `dist/my-lib` folder at the root of your workspace.
|
||||
|
||||
1. To make sure your schematics source files get compiled into the library bundle, add the following scripts to the `package.json` file in your library project's root folder (`projects/my-lib`).
|
||||
|
||||
|
@ -201,7 +201,7 @@ The user can specify the project on the command line, or allow it to default.
|
|||
In either case, your code needs to identify the specific project to which this schematic is being applied, so that you can retrieve information from the project configuration.
|
||||
|
||||
You can do this using the `Tree` object that is passed in to the factory function.
|
||||
The `Tree` methods give you access to the complete file tree in your workspace, allowing you to read and write files during the execution of the schematic.
|
||||
The `Tree` methods give you access to the complete file tree in your workspace, allowing you to read and write files during the execution of the schematic.
|
||||
|
||||
### Get the project configuration
|
||||
|
||||
|
@ -249,7 +249,7 @@ A `Rule` can use external template files, transform them, and return another `Ru
|
|||
* The `url()` method reads source files from your filesystem, relative to the schematic.
|
||||
* The `applyTemplates()` method receives an argument of methods and properties you want make available to the schematic template and the schematic filenames. It returns a `Rule`. This is where you define the `classify()` and `dasherize()` methods, and the `name` property.
|
||||
* The `classify()` method takes a value and returns the value in title case. For example, if the provided name is `my service`, it is returned as `MyService`
|
||||
* The `dasherize()` method takes a value and returns the value in dashed and lowercase. For example, if the provided name is MyService, it is returned as `my-service.
|
||||
* The `dasherize()` method takes a value and returns the value in dashed and lowercase. For example, if the provided name is MyService, it is returned as `my-service.
|
||||
* The `move` method moves the provided source files to their destination when the schematic is applied.
|
||||
|
||||
1. Finally, the rule factory must return a rule.
|
||||
|
|
|
@ -42,7 +42,7 @@ As a library developer, you can create your own collections of custom schematics
|
|||
|
||||
* An *add schematic* allows developers to install your library in an Angular workspace using `ng add`.
|
||||
|
||||
* *Generation schematics* can tell the `ng generate` subcommands how to modify projects, add configurations and scripts, and scaffold artifacts that are defined in your library.
|
||||
* *Generation schematics* can tell the `ng generate` subcommands how to modify projects, add configurations and scripts, and scaffold artifacts that are defined in your library.
|
||||
|
||||
* An *update schematic* can tell the `ng update` command how to update your library's dependencies and adjust for breaking changes when you release a new version.
|
||||
|
||||
|
@ -62,7 +62,7 @@ Partner and third party libraries also support the Angular CLI with add schemati
|
|||
For example, `@ng-bootstrap/schematics` adds [ng-bootstrap](https://ng-bootstrap.github.io/) to an app, and `@clr/angular` installs and sets up [Clarity from VMWare](https://vmware.github.io/clarity/documentation/v1.0/get-started).
|
||||
|
||||
An add schematic can also update a project with configuration changes, add additional dependencies (such as polyfills), or scaffold package-specific initialization code.
|
||||
For example, the `@angular/pwa` schematic turns your application into a PWA by adding an app manifest and service worker, and the `@angular/elements` schematic adds the `document-register-element.js` polyfill and dependencies for Angular Elements.
|
||||
For example, the `@angular/pwa` schematic turns your application into a PWA by adding an app manifest and service worker, and the `@angular/elements` schematic adds the `document-register-element.js` polyfill and dependencies for Angular Elements.
|
||||
|
||||
### Generation schematics
|
||||
|
||||
|
|
|
@ -76,7 +76,7 @@ To simulate a network issue, disable network interaction for your application. I
|
|||
|
||||
<figure class="lightbox">
|
||||
<div class="card">
|
||||
<img src="generated/images/guide/service-worker/offline-checkbox.png" alt="The offline checkbox in the Network tab pis checked">
|
||||
<img src="generated/images/guide/service-worker/offline-checkbox.png" alt="The offline checkbox in the Network tab is checked">
|
||||
</div>
|
||||
</figure>
|
||||
|
||||
|
|
|
@ -25,8 +25,8 @@ That's dirty and undermines your chances of running the app outside of a browser
|
|||
<div class="alert is-helpful">
|
||||
|
||||
Running your app outside a browser means that you can take advantage of server-side
|
||||
pre-rendering for near-instant first app render times and for SEO. It means you could run from
|
||||
inside a Web Worker to improve your app's responsiveness by using multiple threads. And it
|
||||
pre-rendering for near-instant first app render times and for SEO. It means you could run from
|
||||
inside a Web Worker to improve your app's responsiveness by using multiple threads. And it
|
||||
means that you could run your app inside Electron.js or Windows Universal to deliver it to the desktop.
|
||||
|
||||
</div>
|
||||
|
@ -74,4 +74,3 @@ If you bootstrap your application into a different platform,
|
|||
you'll have to provide a different `Title` service that understands
|
||||
the concept of a "document title" for that specific platform.
|
||||
Ideally, the application itself neither knows nor cares about the runtime environment.
|
||||
|
||||
|
|
|
@ -938,7 +938,7 @@ followed by a dot (`.`) and the name of a CSS style property: `[style.style-prop
|
|||
<code-example path="attribute-binding/src/app/app.component.html" region="style-binding" header="src/app/app.component.html"></code-example>
|
||||
|
||||
Some style binding styles have a unit extension.
|
||||
The following example conditionally sets the font size in “em” and “%” units .
|
||||
The following example conditionally sets the font size in “em” and “%” units.
|
||||
|
||||
<code-example path="attribute-binding/src/app/app.component.html" region="style-binding-condition" header="src/app/app.component.html"></code-example>
|
||||
|
||||
|
|
|
@ -188,7 +188,7 @@ When the CLI commands `ng test` and `ng e2e` are generally running the CI tests
|
|||
|
||||
There are configuration files for both the [Karma JavaScript test runner](https://karma-runner.github.io/latest/config/configuration-file.html)
|
||||
and [Protractor](https://www.protractortest.org/#/api-overview) end-to-end testing tool,
|
||||
which you must adjust to start Chrome without sandboxing.
|
||||
which you must adjust to start Chrome without sandboxing.
|
||||
|
||||
We'll be using [Headless Chrome](https://developers.google.com/web/updates/2017/04/headless-chrome#cli) in these examples.
|
||||
|
||||
|
@ -235,7 +235,7 @@ Now you can run the following commands to use the `--no-sandbox` flag:
|
|||
## Enable code coverage reports
|
||||
|
||||
The CLI can run unit tests and create code coverage reports.
|
||||
Code coverage reports show you any parts of our code base that may not be properly tested by your unit tests.
|
||||
Code coverage reports show you any parts of our code base that may not be properly tested by your unit tests.
|
||||
|
||||
To generate a coverage report run the following command in the root of your project.
|
||||
|
||||
|
@ -243,7 +243,7 @@ To generate a coverage report run the following command in the root of your proj
|
|||
ng test --no-watch --code-coverage
|
||||
</code-example>
|
||||
|
||||
When the tests are complete, the command creates a new `/coverage` folder in the project. Open the `index.html` file to see a report with your source code and code coverage values.
|
||||
When the tests are complete, the command creates a new `/coverage` folder in the project. Open the `index.html` file to see a report with your source code and code coverage values.
|
||||
|
||||
If you want to create code-coverage reports every time you test, you can set the following option in the CLI configuration file, `angular.json`:
|
||||
|
||||
|
|
|
@ -127,7 +127,7 @@ The `transition()` function takes additional selector values, `:increment` and `
|
|||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
**Note:** The following example uses `query()` and `stagger()` methods, which is discussed in the [complex sequences](guide/complex-animation-sequences#complex-sequence) page.
|
||||
**Note:** The following example uses `query()` and `stagger()` methods, which is discussed in the [complex sequences](guide/complex-animation-sequences#complex-sequence) page.
|
||||
|
||||
</div>
|
||||
|
||||
|
|
|
@ -968,7 +968,7 @@ Once you introduce the Angular Router, using the Angular Router triggers navigat
|
|||
|
||||
You can take advantage of Ahead-of-time (AOT) compilation on hybrid apps just like on any other
|
||||
Angular application.
|
||||
The setup for an hybrid app is mostly the same as described in
|
||||
The setup for a hybrid app is mostly the same as described in
|
||||
[the Ahead-of-time Compilation chapter](guide/aot-compiler)
|
||||
save for differences in `index.html` and `main-aot.ts`
|
||||
|
||||
|
@ -1506,7 +1506,7 @@ This is something you'll do to all components as you upgrade them. Simultaneousl
|
|||
with the AngularJS to Angular upgrade you're also migrating code from scripts to modules.
|
||||
|
||||
At this point, you can switch the two components to use the new service
|
||||
instead of the old one. While you `$inject` it as the downgraded `phone` factory,
|
||||
instead of the old one. While you `$inject` it as the downgraded `phone` factory,
|
||||
it's really an instance of the `Phone` class and you annotate its type accordingly:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-list/phone-list.component.ajs.ts" header="app/phone-list/phone-list.component.ts">
|
||||
|
|
|
@ -69,7 +69,7 @@ In this case, `target` refers to the [`<input>` element](https://developer.mozil
|
|||
`event.target.value` returns the current contents of that element.
|
||||
|
||||
After each call, the `onKey()` method appends the contents of the input box value to the list
|
||||
in the component's `values` property, followed by a separator character (|).
|
||||
in the component's `values` property, followed by a separator character (|).
|
||||
The [interpolation](guide/template-syntax#interpolation)
|
||||
displays the accumulating input box changes from the `values` property.
|
||||
|
||||
|
@ -276,7 +276,7 @@ get the input box value and pass *that* to `addHero`.
|
|||
|
||||
* **Keep template statements simple** —
|
||||
The `(blur)` event is bound to two JavaScript statements.
|
||||
The first statement calls `addHero`. The second statement, `newHero.value=''`,
|
||||
The first statement calls `addHero`. The second statement, `newHero.value=''`,
|
||||
clears the input box after a new hero is added to the list.
|
||||
|
||||
|
||||
|
|
|
@ -121,7 +121,7 @@ Some scripts extend other libraries; for instance with JQuery plugins:
|
|||
$('.test').myPlugin();
|
||||
```
|
||||
|
||||
In this case, the installed `@types/jquery` doesn't include `myPlugin`, so you need to add an interface in `src/typings.d.ts`. For example:
|
||||
In this case, the installed `@types/jquery` doesn't include `myPlugin`, so you need to add an interface in `src/typings.d.ts`. For example:
|
||||
|
||||
```
|
||||
interface JQuery {
|
||||
|
|
|
@ -11,7 +11,7 @@ This cookbook describes the steps required to set up and use Angular app files i
|
|||
|
||||
|
||||
There is no *live example* for this cookbook because it describes Visual Studio, not
|
||||
the Angular application itself. It uses the starter Angular application created by the CLI command [`ng new`](cli/new) as an example.
|
||||
the Angular application itself. It uses the starter Angular application created by the CLI command [`ng new`](cli/new) as an example.
|
||||
|
||||
|
||||
</div>
|
||||
|
@ -30,8 +30,8 @@ Visual Studio 2015, follow these steps:
|
|||
|
||||
If you prefer a `File | New Project` experience and are using **ASP.NET Core**,
|
||||
then consider the _experimental_
|
||||
<a href="http://blog.stevensanderson.com/2016/10/04/angular2-template-for-visual-studio/">ASP.NET Core + Angular template for Visual Studio 2015</a>.
|
||||
Note that the resulting code does not map to the docs. Adjust accordingly.
|
||||
<a href="http://blog.stevensanderson.com/2016/10/04/angular2-template-for-visual-studio/">ASP.NET Core + Angular template for Visual Studio 2015</a>.
|
||||
Note that the resulting code does not map to the docs. Adjust accordingly.
|
||||
|
||||
|
||||
</div>
|
||||
|
@ -47,7 +47,7 @@ Note that the resulting code does not map to the docs. Adjust accordingly.
|
|||
|
||||
Install **[Node.js® and npm](https://nodejs.org/en/download/)**
|
||||
if they are not already on your machine.
|
||||
See [Local Environment Setup](guide/setup-local "Setting up for Local Development") for supported versions and instructions.
|
||||
See [Local Environment Setup](guide/setup-local "Setting up for Local Development") for supported versions and instructions.
|
||||
|
||||
|
||||
|
||||
|
@ -115,10 +115,10 @@ restart it to make sure everything is clean.
|
|||
Step 1: Create a starter Angular app
|
||||
</h2>
|
||||
|
||||
|
||||
Follow the instructions in [Local Environment Setup](guide/setup-local "Setting up for Local Development") to create a starter Angular app using the CLI command [`ng new`](cli/new).
|
||||
|
||||
|
||||
Follow the instructions in [Local Environment Setup](guide/setup-local "Setting up for Local Development") to create a starter Angular app using the CLI command [`ng new`](cli/new).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -165,7 +165,7 @@ Include the files in the Visual Studio project as follows:
|
|||
* src/index.html
|
||||
* package.json
|
||||
* src/tsconfig.json
|
||||
|
||||
|
||||
|
||||
|
||||
<h2 id='restore'>
|
||||
|
@ -177,7 +177,7 @@ Include the files in the Visual Studio project as follows:
|
|||
Restore the packages required for an Angular application as follows:
|
||||
|
||||
* Right-click on the `package.json` file in Solution Explorer and select `Restore Packages`.
|
||||
<br>This uses `npm` to install all of the packages defined in the `package.json` file.
|
||||
<br>This uses `npm` to install all of the packages defined in the `package.json` file.
|
||||
It may take some time.
|
||||
* If desired, open the Output window (`View` | `Output`) to watch the npm commands execute.
|
||||
* Ignore the warnings.
|
||||
|
@ -199,12 +199,12 @@ Right-click `index.html` in Solution Explorer and select option `Set As Start Pa
|
|||
|
||||
### To run in VS with F5
|
||||
|
||||
Most Visual Studio developers like to press the F5 key and see the IIS server come up.
|
||||
To use the IIS server with the Getting Started app, you must make the following three changes.
|
||||
Most Visual Studio developers like to press the F5 key and see the IIS server come up.
|
||||
To use the IIS server with the Getting Started app, you must make the following three changes.
|
||||
|
||||
1. In `index.html`, change base href from `<base href="/">` to `<base href="/src/">`.
|
||||
2. Also in `index.html`, change the scripts to use `/node_modules` with a slash
|
||||
instead of `node_modules` without the slash.
|
||||
2. Also in `index.html`, change the scripts to use `/node_modules` with a slash
|
||||
instead of `node_modules` without the slash.
|
||||
3. In `src/systemjs.config.js`, near the top of the file,
|
||||
change the npm `path` to `/node_modules/` with a slash.
|
||||
|
||||
|
@ -227,7 +227,7 @@ If your app uses routing, you need to teach the server to always return
|
|||
`index.html` when the user asks for an HTML page
|
||||
for reasons explained in the [Deployment](guide/deployment#fallback) guide.
|
||||
|
||||
Everything seems fine while you move about _within_ the app.
|
||||
Everything seems fine while you move about _within_ the app.
|
||||
But you'll see the problem right away if you refresh the browser
|
||||
or paste a link to an app page (called a "deep link") into the browser address bar.
|
||||
|
||||
|
@ -241,11 +241,11 @@ This section walks through the steps to adapt the Getting Started application.
|
|||
|
||||
#### Configure IIS rewrite rules
|
||||
|
||||
Visual Studio ships with IIS Express, which has the rewrite module baked in.
|
||||
Visual Studio ships with IIS Express, which has the rewrite module baked in.
|
||||
However, if you're using regular IIS you'll have to install the rewrite
|
||||
module.
|
||||
module.
|
||||
|
||||
Tell Visual Studio how to handle requests for route app pages by adding these
|
||||
Tell Visual Studio how to handle requests for route app pages by adding these
|
||||
rewrite rules near the bottom of the `web.config`:
|
||||
|
||||
|
||||
|
@ -274,7 +274,7 @@ rewrite rules near the bottom of the `web.config`:
|
|||
|
||||
|
||||
The match url, `<match url=".*" />`, will rewrite every request. You'll have to adjust this if
|
||||
you want some requests to get through, such as web API requests.
|
||||
you want some requests to get through, such as web API requests.
|
||||
|
||||
The URL in `<action type="Rewrite" url="/src/"/>` should
|
||||
match the base href in `index.html`.
|
||||
|
@ -300,4 +300,4 @@ It's faster to run without the debugger by pressing `Ctrl-F5`.
|
|||
The default browser opens and displays the Getting Started sample application.
|
||||
|
||||
Try editing any of the project files. Save and refresh the browser to
|
||||
see the changes.
|
||||
see the changes.
|
||||
|
|
|
@ -136,13 +136,13 @@ See the example in [Build target](#build-target) below.
|
|||
* The `architect/build` section configures defaults for options of the `ng build` command.
|
||||
See [Build target](#build-target) below for more information.
|
||||
|
||||
* The `architect/serve` section overrides build defaults and supplies additional serve defaults for the `ng serve` command. In addition to the options available for the `ng build` command, it adds options related to serving the app.
|
||||
* The `architect/serve` section overrides build defaults and supplies additional serve defaults for the `ng serve` command. In addition to the options available for the `ng build` command, it adds options related to serving the app.
|
||||
|
||||
* The `architect/e2e` section overrides build-option defaults for building end-to-end testing apps using the `ng e2e` command.
|
||||
|
||||
* The `architect/test` section overrides build-option defaults for test builds and supplies additional test-running defaults for the `ng test` command.
|
||||
|
||||
* The `architect/lint` section configures defaults for options of the `ng lint` command, which performs code analysis on project source files. The default linting tool for Angular is [TSLint](https://palantir.github.io/tslint/).
|
||||
* The `architect/lint` section configures defaults for options of the `ng lint` command, which performs code analysis on project source files. The default linting tool for Angular is [TSLint](https://palantir.github.io/tslint/).
|
||||
|
||||
* The `architect/extract-i18n` section configures defaults for options of the `ng-xi18n` tool used by the `ng xi18n` command, which extracts marked message strings from source code and outputs translation files.
|
||||
|
||||
|
@ -184,7 +184,7 @@ Some additional options can only be set through the configuration file, either b
|
|||
|
||||
| OPTIONS PROPERTIES | DESCRIPTION |
|
||||
| :------------------------- | :---------------------------- |
|
||||
| `assets` | An object containing paths to static assets to add to the global context of the project. The default paths point to the project's icon file and its `assets` folder. See more in [Assets configuration](#asset-config) below. |
|
||||
| `assets` | An object containing paths to static assets to add to the global context of the project. The default paths point to the project's icon file and its `assets` folder. See more in [Assets configuration](#asset-config) below. |
|
||||
| `styles` | An array of style files to add to the global context of the project. Angular CLI supports CSS imports and all major CSS preprocessors: [sass/scss](http://sass-lang.com/), [less](http://lesscss.org/), and [stylus](http://stylus-lang.com/). See more in [Styles and scripts configuration](#style-script-config) below. |
|
||||
| `stylePreprocessorOptions` | An object containing option-value pairs to pass to style preprocessors. See more in [Styles and scripts configuration](#style-script-config) below. |
|
||||
| `scripts` | An object containing JavaScript script files to add to the global context of the project. The scripts are loaded exactly as if you had added them in a `<script>` tag inside `index.html`. See more in [Styles and scripts configuration](#style-script-config) below. |
|
||||
|
|
|
@ -66,7 +66,7 @@ Next, you'll add a checkout form at the bottom of the "Cart" page.
|
|||
<code-example path="getting-started/src/app/cart/cart.component.html" region="checkout-form-1">
|
||||
</code-example>
|
||||
|
||||
1. Add input fields for `name` and `address`. Use the `formControlName` attribute binding to bind the `checkoutForm` form controls for `name` and `address` to their input fields. The final complete component is shown below:
|
||||
1. Add input fields for `name` and `address`. Use the `formControlName` attribute binding to bind the `checkoutForm` form controls for `name` and `address` to their input fields. The final complete component is shown below:
|
||||
|
||||
<code-example path="getting-started/src/app/cart/cart.component.html" region="checkout-form-2">
|
||||
</code-example>
|
||||
|
@ -85,4 +85,3 @@ After putting a few items in the cart, users can now review their items, enter n
|
|||
Congratulations! You have a complete online store application with a product catalog, a shopping cart, and a checkout function.
|
||||
|
||||
[Continue to the "Deployment" section](start/deployment "Getting Started: Deployment") to move to local development, or deploy your app to Firebase or your own server.
|
||||
|
||||
|
|
|
@ -15,7 +15,7 @@ This guide uses the StackBlitz Generator to show you a ready-made, simple applic
|
|||
<header>New to web development?</header>
|
||||
|
||||
|
||||
There are many resources to complement the Angular docs. Mozilla's MDN docs include both [HTML](https://developer.mozilla.org/en-US/docs/Learn/HTML "Learning HTML: Guides and tutorials") and [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript "JavaScript") introductions. [TypeScript's docs](https://www.typescriptlang.org/docs/home.html "TypeScript documentation") include a 5-minute tutorial. Various online course platforms, such as [Udemy](http://www.udemy.com "Udemy online courses") and [Codecademy](https://www.codecademy.com/ "Codeacademy online courses"), also cover web development basics.
|
||||
There are many resources to complement the Angular docs. Mozilla's MDN docs include both [HTML](https://developer.mozilla.org/en-US/docs/Learn/HTML "Learning HTML: Guides and tutorials") and [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript "JavaScript") introductions. [TypeScript's docs](https://www.typescriptlang.org/docs/home.html "TypeScript documentation") include a 5-minute tutorial. Various online course platforms, such as [Udemy](http://www.udemy.com "Udemy online courses") and [Codecademy](https://www.codecademy.com/ "Codecademy online courses"), also cover web development basics.
|
||||
|
||||
|
||||
</div>
|
||||
|
@ -366,4 +366,3 @@ You've also learned how the component class and template interact, and how compo
|
|||
To continue exploring Angular, choose either of the following options:
|
||||
* [Continue to the "Routing" section](start/routing "Getting Started: Routing") to create a product details page that can be accessed by clicking a product name and that has its own URL pattern.
|
||||
* [Skip ahead to the "Deployment" section](start/deployment "Getting Started: Deployment") to move to local development, or deploy your app to Firebase or your own server.
|
||||
|
||||
|
|
|
@ -55,7 +55,7 @@ Go to the workspace directory and launch the application.
|
|||
The `ng serve` command builds the app, starts the development server,
|
||||
watches the source files, and rebuilds the app as you make changes to those files.
|
||||
|
||||
The `--open` flag opens a browser to `http://localhost:4200/`.
|
||||
The `--open` flag opens a browser to `http://localhost:4200/`.
|
||||
|
||||
</div>
|
||||
|
||||
|
|
|
@ -208,7 +208,7 @@ You just have to apply the `.selected` class to the `<li>` when the user clicks
|
|||
The Angular [class binding](guide/template-syntax#class-binding) makes it easy to add and remove a CSS class conditionally.
|
||||
Just add `[class.some-css-class]="some-condition"` to the element you want to style.
|
||||
|
||||
Add the following `[class.selected]` binding to the `<li>` in the `HeroesComponent` template:
|
||||
Add the following `[class.selected]` binding to the `<li>` in the `HeroesComponent` template:
|
||||
|
||||
<code-example path="toh-pt2/src/app/heroes/heroes.component.1.html" region="class-selected" header="heroes.component.html (toggle the 'selected' CSS class)"></code-example>
|
||||
|
||||
|
|
|
@ -95,7 +95,7 @@ The `HeroService` is now ready to plug into the `HeroesComponent`.
|
|||
|
||||
<div class="alert is-important">
|
||||
|
||||
This is an interim code sample that will allow you to provide and use the `HeroService`. At this point, the code will differ from the `HeroService` in the ["final code review"](#final-code-review).
|
||||
This is an interim code sample that will allow you to provide and use the `HeroService`. At this point, the code will differ from the `HeroService` in the ["final code review"](#final-code-review).
|
||||
|
||||
</div>
|
||||
|
||||
|
|
|
@ -44,7 +44,7 @@ Replace it with the following:
|
|||
<code-example path="toh-pt5/src/app/app-routing.module.1.ts" header="src/app/app-routing.module.ts (updated)">
|
||||
</code-example>
|
||||
|
||||
First, `AppRoutingModule` imports `RouterModule` and `Routes` so the app can have routing functionality. The next import, `HeroesComponent`, will give the Router somewhere to go once you configure the routes.
|
||||
First, `AppRoutingModule` imports `RouterModule` and `Routes` so the app can have routing functionality. The next import, `HeroesComponent`, will give the Router somewhere to go once you configure the routes.
|
||||
|
||||
Notice that the `CommonModule` references and `declarations` array are unnecessary, so are no
|
||||
longer part of `AppRoutingModule`. The following sections explain the rest of the `AppRoutingModule` in more detail.
|
||||
|
|
|
@ -324,7 +324,7 @@ The HTML for the list of heroes should look like this:
|
|||
<code-example path="toh-pt6/src/app/heroes/heroes.component.html" region="list" header="src/app/heroes/heroes.component.html (list of heroes)"></code-example>
|
||||
|
||||
To position the delete button at the far right of the hero entry,
|
||||
add some CSS to the `heroes.component.css`. You'll find that CSS
|
||||
add some CSS to the `heroes.component.css`. You'll find that CSS
|
||||
in the [final review code](#heroescomponent) below.
|
||||
|
||||
Add the `delete()` handler to the component class.
|
||||
|
|
Loading…
Reference in New Issue