docs(aio): update to remark syntax
This commit is contained in:
parent
374bf1ed98
commit
df619adc76
|
@ -17,7 +17,7 @@ performance found in pure CSS animations. You can also tightly integrate your
|
|||
animation logic with the rest of your application code, for ease of control.
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -30,7 +30,7 @@ add it to your page.
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -48,14 +48,14 @@ add it to your page.
|
|||
* [Animation callbacks](guide/animations#animation-callbacks).
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
The examples in this page are available as a <live-example></live-example>.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -101,7 +101,7 @@ hero is active, the element appears in a slightly larger size and lighter color.
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -109,7 +109,7 @@ In this example, you are defining animation styles (color and transform) inline
|
|||
animation metadata.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -273,7 +273,7 @@ are different on enter and leave: the element enters from the left
|
|||
and leaves to the right.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -287,7 +287,7 @@ These two common animations have their own aliases:
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -53,13 +53,13 @@ An Angular application consists largely of components and their HTML templates.
|
|||
Before the browser can render the application,
|
||||
the components and templates must be converted to executable JavaScript by the _Angular compiler_.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
<a href="https://www.youtube.com/watch?v=kW9cJsvcsGo" target="_blank">Watch compiler author Tobias Bosch explain the Angular Compiler</a> at AngularConnect 2016.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -205,7 +205,7 @@ Initiate AOT compilation from the command line using the previously installed `n
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -217,7 +217,7 @@ Windows users should surround the `ngc` command in double quotes:
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -231,7 +231,7 @@ Each component factory creates an instance of the component at runtime by combin
|
|||
and a JavaScript representation of the component's template.
|
||||
Note that the original component class is still referenced internally by the generated factory.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -242,20 +242,20 @@ JIT compilation generates these same _NgFactories_ in memory where they are larg
|
|||
AOT compilation reveals them as separate, physical files.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
Do not edit the _NgFactories_! Re-compilation replaces these files and all edits will be lost.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -330,7 +330,7 @@ It produces a final code _bundle_ that excludes code that is exported, but never
|
|||
|
||||
Rollup can only tree shake `ES2015` modules which have `import` and `export` statements.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -338,7 +338,7 @@ Recall that `tsconfig-aot.json` is configured to produce `ES2015` modules.
|
|||
It's not important that the code itself be written with `ES2015` syntax such as `class` and `const`.
|
||||
What matters is that the code uses ES `import` and `export` statements rather than `require` statements.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -409,7 +409,7 @@ Add the following to the `plugins` array:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -417,7 +417,7 @@ In a production setting, you would also enable gzip on the web server to compres
|
|||
the code into an even smaller package going over the wire.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -433,7 +433,7 @@ Execute the Rollup process with this command:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -445,7 +445,7 @@ Windows users should surround the `rollup` command in double quotes:
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -683,7 +683,7 @@ You'll need separate TypeScript configuration files such as these:
|
|||
|
||||
|
||||
|
||||
~~~ {.callout.is-helpful}
|
||||
<div class="callout is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -701,7 +701,7 @@ In a more typical project, `node_modules` would be a sibling of `tsconfig-aot.js
|
|||
and `"typeRoots"` would be set to `"node_modules/@types/"`.
|
||||
Edit your `tsconfig-aot.json` to fit your project's file structure.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -725,7 +725,7 @@ Rollup does the tree shaking as before.
|
|||
### Running the application
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -737,7 +737,7 @@ github repository and prepared it for development as explained in the repo's REA
|
|||
|
||||
The _Tour of Heroes_ source code is in the `public/docs/_examples/toh-6/ts` folder.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -777,13 +777,13 @@ Copy the AOT distribution files into the `/aot` folder with the node script:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
You won't do that again until there are updates to `zone.js` or the `core-js` shim for old browsers.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -54,18 +54,18 @@ So every such application includes the `BrowserModule` in its _root_ `AppModule`
|
|||
Other guide and cookbook pages will tell you when you need to add additional modules to this array.
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
**Only `NgModule` classes** go in the `imports` array. Do not put any other kind of class in `imports`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -81,7 +81,7 @@ The _module's_ `imports` array appears _exclusively_ in the `@NgModule` metadata
|
|||
It tells Angular about specific _other_ Angular modules — all of them classes decorated with `@NgModule` —
|
||||
that the application needs to function properly.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -101,7 +101,7 @@ You'll learn to create two other kinds of classes —
|
|||
that you must also add to the `declarations` array.
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -109,7 +109,7 @@ that you must also add to the `declarations` array.
|
|||
Do not put any other kind of class in `declarations`; _not_ `NgModule` classes, _not_ service classes, _not_ model classes.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -46,7 +46,7 @@ The architecture diagram identifies the eight main building blocks of an Angular
|
|||
Learn these building blocks, and you're on your way.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -56,7 +56,7 @@ Learn these building blocks, and you're on your way.
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -84,7 +84,7 @@ a workflow, or a closely related set of capabilities.
|
|||
|
||||
An Angular module, whether a _root_ or _feature_, is a class with an `@NgModule` decorator.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -94,7 +94,7 @@ what those classes mean and how they should work.
|
|||
<a href="https://medium.com/google-developers/exploring-es7-decorators-76ecb65fb841#.x5c2ndtx0" target="_blank">
|
||||
Learn more</a> about decorators on the web.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -121,13 +121,13 @@ Here's a simple root module:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
The `export` of `AppComponent` is just to show how to export; it isn't actually necessary in this example. A root module has no reason to _export_ anything because other components don't need to _import_ the root module.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -165,13 +165,13 @@ Other JavaScript modules use *import statements* to access public objects from o
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
<a href="http://exploringjs.com/es6/ch_modules.html" target="_blank">Learn more about the JavaScript module system on the web.</a>
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -224,18 +224,18 @@ It's easy to confuse the two systems because they share the common vocabulary of
|
|||
Hang in there. The confusion yields to clarity with time and experience.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Learn more from the [Angular modules](guide/ngmodule) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -276,7 +276,7 @@ Angular creates, updates, and destroys components as the user moves through the
|
|||
Your app can take action at each moment in this lifecycle through optional [lifecycle hooks](guide/lifecycle-hooks), like `ngOnInit()` declared above.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -322,7 +322,7 @@ The `HeroDetailComponent` is a **child** of the `HeroListComponent`.
|
|||
Notice how `<hero-detail>` rests comfortably among native HTML elements. Custom components mix seamlessly with native HTML in the same layouts.
|
||||
<br class="l-clear-both">
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -395,7 +395,7 @@ The architectural takeaway is that you must add metadata to your code
|
|||
so that Angular knows what to do.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -470,7 +470,7 @@ between a template and its component.<br class="l-clear-both">
|
|||
|
||||
Data binding is also important for communication between parent and child components.<br class="l-clear-both">
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -492,14 +492,14 @@ a `@Component` decorator is actually a `@Directive` decorator extended with temp
|
|||
<br class="l-clear-both">
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
While **a component is technically a directive**,
|
||||
components are so distinctive and central to Angular applications that this architectural overview separates components from directives.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -548,7 +548,7 @@ Of course, you can also write your own directives. Components such as
|
|||
<!-- PENDING: link to where to learn more about other kinds! -->
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -616,7 +616,7 @@ Angular does help you *follow* these principles by making it easy to factor your
|
|||
application logic into services and make those services available to components through *dependency injection*.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -707,7 +707,7 @@ Points to remember about dependency injection:
|
|||
* Register *providers* with injectors.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -96,7 +96,7 @@ Here, the directive's selector is `[myHighlight]`.
|
|||
Angular locates all elements in the template that have an attribute named `myHighlight`.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -112,7 +112,7 @@ that prefix is reserved for Angular and using it could cause bugs that are diffi
|
|||
For a simple demo, the short prefix, `my`, helps distinguish your custom directive.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -173,7 +173,7 @@ Now when the app runs, the `myHighlight` directive highlights the paragraph text
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -198,7 +198,7 @@ After specifying `HighlightDirective` in the `declarations` array,
|
|||
Angular knows it can apply the directive to components declared in this module.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -240,7 +240,7 @@ The `@HostListener` decorator lets you subscribe to events of the DOM
|
|||
element that hosts an attribute directive, the `<p>` in this case.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -252,7 +252,7 @@ There are at least three problems with _that_ approach:
|
|||
1. Talking to DOM API directly isn't a best practice.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -197,7 +197,7 @@ Angular supports most recent browsers. This includes the following specific vers
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -206,7 +206,7 @@ using <a href="https://saucelabs.com/" target="_blank">SauceLabs</a> and
|
|||
<a href="https://www.browserstack.com" target="_blank">Browserstack</a>.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -229,7 +229,7 @@ You may need additional polyfills for specific features.
|
|||
The tables below can help you determine which polyfills to load, depending on the browsers you target and the features you use.
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -238,7 +238,7 @@ You may need additional polyfills to support features not covered by this list.
|
|||
Note that polyfills cannot magically transform an old, slow browser into a modern, fast one.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -76,7 +76,7 @@ All of these services are implemented as classes.
|
|||
Service classes can act as their own providers which is why listing them in the `providers` array
|
||||
is all the registration you need.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -85,7 +85,7 @@ Angular creates a service instance from a class provider by using `new`.
|
|||
Read more about providers in the [Dependency Injection](guide/dependency-injection#!)
|
||||
guide.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -199,7 +199,7 @@ and add `@Injectable()` to fix it. Add `@Injectable()` from the start for the sa
|
|||
of consistency and to avoid future pain.
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -207,11 +207,11 @@ Although this site recommends applying `@Injectable()` to all service classes, d
|
|||
Some developers prefer to add it only where needed and that's a reasonable policy too.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -221,7 +221,7 @@ In Angular with TypeScript, a *single* decorator—*any* decorator—is
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
{@a service-scope}
|
||||
|
||||
|
@ -261,7 +261,7 @@ that is visible only to the component and its children, if any.
|
|||
You could also provide the `HeroService` to a *different* component elsewhere in the application.
|
||||
That would result in a *different* instance of the service, living in a *different* injector.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -270,12 +270,12 @@ including the `HeroBiosComponent`, `HeroOfTheMonthComponent`, and `HeroesBaseCom
|
|||
Each of these components has its own `HeroService` instance managing its own independent collection of heroes.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -284,7 +284,7 @@ This much Dependency Injection knowledge may be all that many Angular developers
|
|||
ever need to build their applications. It doesn't always have to be more complicated.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
{@a multiple-service-instances}
|
||||
|
||||
|
@ -527,7 +527,7 @@ It may already have that value in its internal container.
|
|||
If it doesn't, it may be able to make one with the help of a ***provider***.
|
||||
A *provider* is a recipe for delivering a service associated with a *token*.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -536,7 +536,7 @@ to its parent injector, where the process repeats until there are no more inject
|
|||
If the search is futile, the injector throws an error—unless the request was [optional](guide/cb-dependency-injection#optional).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -668,14 +668,14 @@ The second provider substitutes the `DateLoggerService` for the `LoggerService`.
|
|||
The `LoggerService` is already registered at the `AppComponent` level.
|
||||
When _this component_ requests the `LoggerService`, it receives the `DateLoggerService` instead.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
This component and its tree of child components receive the `DateLoggerService` instance.
|
||||
Components outside the tree continue to receive the original `LoggerService` instance.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -736,7 +736,7 @@ The `HeroOfTheMonthComponent` constructor's `logger` parameter is typed as `Mini
|
|||
Behind the scenes, Angular actually sets the `logger` parameter to the full service registered under the `LoggingService` token which happens to be the `DateLoggerService` that was [provided above](guide/cb-dependency-injection#useclass).
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -748,7 +748,7 @@ The following image, which displays the logging date, confirms the point:
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -798,7 +798,7 @@ After some undisclosed work, the function returns the string of names
|
|||
and Angular injects it into the `runnersUp` parameter of the `HeroOfTheMonthComponent`.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -808,7 +808,7 @@ Look at the <live-example name="cb-dependency-injection"></live-example>
|
|||
for the full source code.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -860,7 +860,7 @@ A ***class-interface*** should define *only* the members that its consumers are
|
|||
Such a narrowing interface helps decouple the concrete class from its consumers.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -887,7 +887,7 @@ The `MinimalLogger` transpiles to this unoptimized, pre-minified JavaScript for
|
|||
Notice that it doesn't have a single member. It never grows no matter how many members you add to the class *as long as those members are typed but not implemented*. Look again at the TypeScript `MinimalLogger` class to confirm that it has no implementation.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -957,7 +957,7 @@ and displays them in the order they arrive from the database.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -966,7 +966,7 @@ This rule makes the component safe to construct under test without fear that it
|
|||
That's why you call the `HeroService` from within the `ngOnInit` rather than the constructor.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1073,7 +1073,7 @@ If you're lucky, they all implement the same base class
|
|||
whose API your `NewsComponent` understands.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1082,7 +1082,7 @@ That's not possible because TypeScript interfaces disappear
|
|||
from the transpiled JavaScript, which doesn't support interfaces.
|
||||
There's no artifact to look for.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1256,7 +1256,7 @@ its class signature doesn't mention `Parent`:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1264,7 +1264,7 @@ The `AlexComponent` *should* implement `Parent` as a matter of proper style.
|
|||
It doesn't in this example *only* to demonstrate that the code will compile and run without the interface
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -13,14 +13,14 @@ Each cookbook page is a collection of recipes focused on a particular Angular fe
|
|||
such as data binding, cross-component interaction, and communicating with a remote server via HTTP.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
The cookbook is just getting started. Many more recipes are on the way.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -38,7 +38,7 @@ You need to set up your development environment before you can do anything.
|
|||
Install **[Node.js® and npm](https://nodejs.org/en/download/)**
|
||||
if they are not already on your machine.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -46,7 +46,7 @@ if they are not already on your machine.
|
|||
by running `node -v` and `npm -v` in a terminal/console window.
|
||||
Older versions produce errors, but newer versions are fine.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -80,7 +80,7 @@ Generate a new project and skeleton application by running the following command
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -88,7 +88,7 @@ Patience please.
|
|||
It takes time to set up a new project, most of it spent installing npm packages.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -779,7 +779,7 @@ These files go in the root folder next to `src/`.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -789,5 +789,5 @@ If you're new to Angular, continue on the
|
|||
[learning path](guide/guide/learning-angular "Angular learning path").
|
||||
You can skip the "Setup" step since you're already using the Angular CLI setup.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
|
|
@ -122,7 +122,7 @@ E2E tests of input property setter with empty and non-empty names:
|
|||
|
||||
Detect and act upon changes to input property values with the `ngOnChanges()` method of the `OnChanges` lifecycle hook interface.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -130,7 +130,7 @@ You may prefer this approach to the property setter when watching multiple, inte
|
|||
|
||||
Learn about `ngOnChanges()` in the [LifeCycle Hooks](guide/lifecycle-hooks) chapter.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -314,14 +314,14 @@ The following example illustrates this technique with the same
|
|||
Neither its appearance nor its behavior will change.
|
||||
The child [CountdownTimerComponent](guide/component-communication#countdown-timer-example) is the same as well.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
The switch from the *local variable* to the *ViewChild* technique
|
||||
is solely for the purpose of demonstration.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -402,7 +402,7 @@ Each `AstronautComponent` is a child of the `MissionControlComponent` and theref
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -414,7 +414,7 @@ That *would not* always be true in a more complex application.
|
|||
You don't add this guard to the `MissionControlComponent` because, as the parent,
|
||||
it controls the lifetime of the `MissionService`.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -143,7 +143,7 @@ through this component to all of its child elements in the DOM.
|
|||
The `/deep/` selector also has the alias `>>>`. You can use either interchangeably.
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -152,7 +152,7 @@ Emulated is the default and most commonly used view encapsulation. For more info
|
|||
[Controlling view encapsulation](guide/component-styles#view-encapsulation) section.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -194,7 +194,7 @@ into a component's `@Component` decorator:
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -205,11 +205,11 @@ That's why the example URL begins `src/app/`.
|
|||
To specify a URL relative to the component file, see [Appendix 2](guide/component-styles#relative-urls).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -225,7 +225,7 @@ To Angular, it's as if you wrote the `styles` array by hand.
|
|||
For information on loading CSS in this manner, refer to the module bundler's documentation.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -133,7 +133,7 @@ The `Car` class no longer creates an `engine` or `tires`.
|
|||
It just consumes them.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -141,7 +141,7 @@ This example leverages TypeScript's constructor syntax for declaring
|
|||
parameters and properties simultaneously.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -163,7 +163,7 @@ conform to the general API requirements of an `engine` or `tires`.
|
|||
Now, if someone extends the `Engine` class, that is not `Car`'s problem.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -181,7 +181,7 @@ The critical point is this: the `Car` class did not have to change.
|
|||
You'll take care of the consumer's problem shortly.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -298,7 +298,7 @@ fix every other use of the `HEROES` mock data.
|
|||
It's better to make a service that hides how the app gets hero data.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -308,7 +308,7 @@ consider writing the service code in its own file.
|
|||
|
||||
See [this note](guide/dependency-injection#one-class-per-file) for details.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -324,7 +324,7 @@ the same mock data as before, but none of its consumers need to know that.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -332,11 +332,11 @@ The `@Injectable()` decorator above the service class is
|
|||
covered [shortly](guide/dependency-injection#injectable).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -347,7 +347,7 @@ You'd also have to rewrite the way components consume the service.
|
|||
This is important in general, but not in this example.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -435,7 +435,7 @@ feature area and nowhere else, it makes sense to register it in
|
|||
the `HeroesComponent`.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -443,7 +443,7 @@ Also see *"Should I add app-wide providers to the root `AppModule` or
|
|||
the root `AppComponent`?"* in the [NgModule FAQ](cookbook/ngmodule-faq#q-root-component-or-module).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -472,7 +472,7 @@ It's a small change:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -499,7 +499,7 @@ Angular injector to inject an instance of
|
|||
`HeroService` whenever it creates a new `HeroListComponent`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -562,14 +562,14 @@ under test:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Learn more in [Testing](guide/testing).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -617,7 +617,7 @@ error when trying to instantiate a class that is not marked as
|
|||
`@Injectable()`.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -628,11 +628,11 @@ You need it because Angular requires constructor parameter metadata
|
|||
in order to inject a `Logger`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
~~~ {.callout.is-helpful}
|
||||
<div class="callout is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -660,7 +660,7 @@ and, therefore, do not technically require it. Here's why:
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -676,7 +676,7 @@ fact `@Injectable()` decorators that
|
|||
identify a class as a target for instantiation by an injector.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -696,11 +696,11 @@ While any decorator will trigger this effect, mark the service class with the
|
|||
to make the intent clear.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
~~~ {.callout.is-critical}
|
||||
<div class="callout is-critical">
|
||||
|
||||
|
||||
|
||||
|
@ -714,7 +714,7 @@ Always write `@Injectable()`, not just `@Injectable`.
|
|||
The application will fail mysteriously if you forget the parentheses.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1000,7 +1000,7 @@ and let the injector pass them along to the factory function:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1012,7 +1012,7 @@ The `Logger` and `UserService` classes serve as tokens for their own class provi
|
|||
The injector resolves these tokens and injects the corresponding services into the matching factory function parameters.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1108,7 +1108,7 @@ You don't have a class to serve as a token.
|
|||
There is no `AppConfig` class.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1137,7 +1137,7 @@ The TypeScript interface disappears from the generated JavaScript.
|
|||
There is no interface type information left for Angular to find at runtime.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1179,7 +1179,7 @@ the help of an `@Inject` decorator:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1187,7 +1187,7 @@ Although the `AppConfig` interface plays no role in dependency injection,
|
|||
it supports typing of the configuration object within the class.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1267,7 +1267,7 @@ You can call `get()` with a second parameter, which is the value to return if th
|
|||
is not found. Angular can't find the service if it's not registered with this or any ancestor injector.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1285,7 +1285,7 @@ Framework developers may take this approach when they
|
|||
must acquire services generically and dynamically.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1302,7 +1302,7 @@ If you define the component before the service,
|
|||
you'll get a runtime null reference error.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1311,5 +1311,5 @@ in this [blog post](http://blog.thoughtram.io/angular/2015/09/03/forward-referen
|
|||
But why flirt with trouble?
|
||||
Avoid the problem altogether by defining components and services in separate files.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
|
|
@ -88,7 +88,7 @@ Otherwise, leave it alone.
|
|||
That's the simplest deployment you can do.
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -98,7 +98,7 @@ Be sure to read about [optimizing for production](guide/deployment#optimize "Opt
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -377,13 +377,13 @@ into a server request for `my/app/some/place/foo.jpg`.
|
|||
During navigation, the Angular router uses the _base href_ as the base path to component, template, and module files.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
See also the [*APP_BASE_HREF*](api/common/index/APP_BASE_HREF-let "API: APP_BASE_HREF") alternative.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -30,7 +30,7 @@ The final UI looks like this:
|
|||
* [Conditional display with NgIf](guide/displaying-data#ngIf).
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -38,7 +38,7 @@ The <live-example></live-example> demonstrates all of the syntax and code
|
|||
snippets described in this page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -75,7 +75,7 @@ interpolation:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -85,7 +85,7 @@ quote (`'`)—allows you to compose a string over several lines, which makes
|
|||
HTML more readable.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -94,7 +94,7 @@ inserts those values into the browser. Angular updates the display
|
|||
when these properties change.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -102,7 +102,7 @@ More precisely, the redisplay occurs after some kind of asynchronous event relat
|
|||
the view, such as a keystroke, a timer completion, or a response to an HTTP request.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -196,7 +196,7 @@ It marks that `<li>` element (and its children) as the "repeater template":
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -204,7 +204,7 @@ Don't forget the leading asterisk (\*) in `*ngFor`. It is an essential part of t
|
|||
For more information, see the [Template Syntax](guide/template-syntax#ngFor) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -218,14 +218,14 @@ to the item (the hero) in the current iteration. Angular uses that variable as t
|
|||
context for the interpolation in the double curly braces.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
In this case, `ngFor` is displaying an array, but `ngFor` can
|
||||
repeat items for any [iterable](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols) object.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -324,7 +324,7 @@ To see it in action, add the following paragraph at the bottom of the template:
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -332,7 +332,7 @@ Don't forget the leading asterisk (\*) in `*ngIf`. It is an essential part of th
|
|||
Read more about `ngIf` and `*` in the [ngIf section](guide/template-syntax#ngIf) of the [Template Syntax](guide/template-syntax) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -345,7 +345,7 @@ see the [template expressions](guide/template-syntax#template-expressions) secti
|
|||
[Template Syntax](guide/template-syntax) page.
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -353,7 +353,7 @@ Angular isn't showing and hiding the message. It is adding and removing the para
|
|||
big chunks of HTML with many data bindings.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -123,7 +123,7 @@ The `loadComponent()` method is doing a lot of the heavy lifting here.
|
|||
Take it step by step. First, it picks an ad.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -137,7 +137,7 @@ using the _remainder_ as the new `currentAddIndex` value. Then, it uses that
|
|||
value to select an `adItem` from the array.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -15,7 +15,7 @@ Improve overall data quality by validating user input for accuracy and completen
|
|||
This cookbook shows how to validate user input in the UI and display useful validation messages
|
||||
using first the template-driven forms and then the reactive forms approach.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -23,7 +23,7 @@ Read more about these choices in the [Forms](guide/forms)
|
|||
and the [Reactive Forms](guide/reactive-forms) guides.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -120,7 +120,7 @@ The full template repeats this kind of layout for each data entry control on the
|
|||
{@a why-check}
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -131,7 +131,7 @@ The checks for `dirty` and `touched` prevent premature display of errors.
|
|||
|
||||
Learn about `dirty` and `touched` in the [Forms](guide/forms) guide.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -338,7 +338,7 @@ Here's how you imported it in the `HeroFormTemplateModule`.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -348,7 +348,7 @@ form template in this cookbook.
|
|||
They're not germane to the validation story. Look at the [live example](guide/form-validation#live-example) if you're interested.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -436,7 +436,7 @@ validating happens in code.
|
|||
but rather for css styling and accessibility.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -447,7 +447,7 @@ Until then, apply the `required` attribute _and_ add the `Validator.required` fu
|
|||
to the control model, as you'll see below.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -459,13 +459,13 @@ The reactive approach does not use data binding to move data into and out of the
|
|||
That's all in code.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
The retreat from data binding is a principle of the reactive paradigm rather than a technical limitation.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -501,13 +501,13 @@ Here's the section of code devoted to that process, paired with the template-dri
|
|||
* Call a `buildForm` method in the `ngOnInit` [lifecycle hook method](guide/lifecycle-hooks#hooks-overview)
|
||||
because that's when you'll have the hero data. Call it again in the `addHero` method.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
A real app would retrieve the hero asynchronously from a data service, a task best performed in the `ngOnInit` hook.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -534,14 +534,14 @@ The `forbiddenNames` validator on the `"name"` control is a custom validator,
|
|||
discussed in a separate [section below](guide/form-validation#custom-validation).
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Learn more about `FormBuilder` in the [Introduction to FormBuilder](guide/reactive-forms#formbuilder) section of Reactive Forms guide.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -567,14 +567,14 @@ The `onSubmit()` method simply replaces the `hero` object with the combined valu
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
This example is lucky in that the `heroForm.value` properties _just happen_ to
|
||||
correspond _exactly_ to the hero data object properties.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -609,7 +609,7 @@ Here's the complete reactive component file, compared to the two template-driven
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -617,7 +617,7 @@ Run the [live example](guide/form-validation#live-example) to see how the reacti
|
|||
and to compare all of the files in this cookbook sample.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -695,7 +695,7 @@ Here is the rest of the directive to help you get an idea of how it all comes to
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -712,13 +712,13 @@ Notice that you get a validation error. Now change from `useExisting` to `useCla
|
|||
This time, when you type “bob”, there's no "bob" error message.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -726,7 +726,7 @@ For more information on attaching behavior to elements,
|
|||
see [Attribute Directives](guide/attribute-directives).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -37,7 +37,7 @@ You can build forms by writing templates in the Angular [template syntax](guide/
|
|||
the form-specific directives and techniques described in this page.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -45,7 +45,7 @@ You can also use a reactive (or model-driven) approach to build forms.
|
|||
However, this page focuses on template-driven forms.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -82,14 +82,14 @@ If you delete the hero name, the form displays a validation error in an attentio
|
|||
Note that the *Submit* button is disabled, and the "required" bar to the left of the input control changes from green to red.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
You can customize the colors and location of the "required" bar with standard CSS.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -213,7 +213,7 @@ Replace the contents of the "QuickStart" version with the following:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -228,11 +228,11 @@ access to all of the template-driven forms features, including `ngModel`.
|
|||
the `HeroFormComponent` component visible throughout this module.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -240,7 +240,7 @@ If a component, directive, or pipe belongs to a module in the `imports` array,
|
|||
If you wrote it and it should belong to this module, _do_ declare it in the `declarations` array.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -260,7 +260,7 @@ Replace the contents of the "QuickStart" version with the following:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -270,7 +270,7 @@ This displays the hero form when the application component is loaded.
|
|||
You've also dropped the `name` field from the class body.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -301,7 +301,7 @@ come from [Twitter Bootstrap](http://getbootstrap.com/css/). These classes are p
|
|||
Bootstrap gives the form a little style.
|
||||
|
||||
|
||||
~~~ {.callout.is-important}
|
||||
<div class="callout is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -315,7 +315,7 @@ Angular makes no use of the `container`, `form-group`, `form-control`, and `btn`
|
|||
the styles of any external library. Angular apps can use any CSS library or none at all.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -385,7 +385,7 @@ Find the `<input>` tag for *Name* and update it like this:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -394,7 +394,7 @@ so you can see what you're doing.
|
|||
You left yourself a note to throw it away when you're done.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -416,7 +416,7 @@ The diagnostic is evidence that values really are flowing from the input box to
|
|||
back again.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -426,7 +426,7 @@ For more information, see
|
|||
the [Template Syntax](guide/template-syntax) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -435,7 +435,7 @@ which makes sense for the hero's name. Any unique value will do, but using a des
|
|||
Defining a `name` attribute is a requirement when using `[(ngModel)]` in combination with a form.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -445,7 +445,7 @@ Each `FormControl` is registered under the name you assigned to the `name` attri
|
|||
Read more in [The NgForm directive](guide/forms#ngForm), later in this page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -463,7 +463,7 @@ After revision, the core of the form should look like this:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -472,7 +472,7 @@ to match the label to its input control.
|
|||
* Each input element has a `name` property that is required by Angular forms to register the control with the form.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -679,7 +679,7 @@ You need a template reference variable to access the input box's Angular control
|
|||
Here you created a variable called `name` and gave it the value "ngModel".
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -689,7 +689,7 @@ tells Angular how to link the reference variable to the directive.
|
|||
You set `name` to `ngModel` because the `ngModel` directive's `exportAs` property happens to be "ngModel".
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -711,7 +711,7 @@ If you ignore the `pristine` state, you would hide the message only when the val
|
|||
If you arrive in this component with a new (blank) hero or an invalid hero,
|
||||
you'll see the error message immediately, before you've done anything.
|
||||
|
||||
Some developers want to the message to display only when the user makes an invalid change.
|
||||
Some developers want the message to display only when the user makes an invalid change.
|
||||
Hiding the message while the control is "pristine" achieves that goal.
|
||||
You'll see the significance of this choice when you [add a new hero](guide/forms#new-hero) to the form.
|
||||
|
||||
|
@ -790,7 +790,7 @@ template reference variable, `#heroForm`, and initialized it with the value "ngF
|
|||
The variable `heroForm` is now a reference to the `NgForm` directive that governs the form as a whole.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -808,7 +808,7 @@ It also has its own `valid` property which is true only *if every contained
|
|||
control* is valid.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -845,7 +845,7 @@ For you, it was as simple as this:
|
|||
Submitting the form isn't terribly dramatic at the moment.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -856,7 +856,7 @@ binding skills.
|
|||
If you aren't interested, skip to this page's conclusion.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -21,7 +21,7 @@ unexpected definitions.
|
|||
|
||||
## Ahead-of-time (AOT) compilation
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -31,13 +31,13 @@ to a module factory, meaning you don't need to include the Angular compiler in y
|
|||
Ahead-of-time compiled applications also benefit from decreased load time and increased performance.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## Angular module
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -50,20 +50,20 @@ called `AppModule` and resides in a file named `app.module.ts`.
|
|||
For details and examples, see the [Angular Modules (NgModule)](guide/ngmodule) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## Annotation
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
In practice, a synonym for [Decoration](guide/glossary#decorator).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -75,7 +75,7 @@ In practice, a synonym for [Decoration](guide/glossary#decorator).
|
|||
|
||||
## Attribute directives
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -88,14 +88,14 @@ For example, you can use the `ngClass` directive to add and remove CSS class nam
|
|||
Learn about them in the [_Attribute Directives_](guide/attribute-directives) guide.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
## Barrel
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -148,24 +148,24 @@ Now a consumer can import what it needs from the barrel.
|
|||
The Angular [scoped packages](guide/glossary#scoped-package) each have a barrel named `index`.
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
You can often achieve the same result using [Angular modules](guide/glossary#angular-module) instead.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## Binding
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -176,13 +176,13 @@ Sometimes refers to a [dependency-injection](guide/glossary#dependency-injection
|
|||
between a "token"—also referred to as a "key"—and a dependency [provider](guide/glossary#provider).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## Bootstrap
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -194,14 +194,14 @@ For more information, see the [Setup](guide/setup) page.
|
|||
You can bootstrap multiple apps in the same `index.html`, each app with its own top-level root.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
## camelCase
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -214,7 +214,7 @@ camelCase is also known as *lower camel case* to distinguish it from *upper came
|
|||
In Angular documentation, "camelCase" always means *lower camel case*.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -223,7 +223,7 @@ In Angular documentation, "camelCase" always means *lower camel case*.
|
|||
|
||||
## Component
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -241,14 +241,14 @@ Those familiar with "MVC" and "MVVM" patterns will recognize
|
|||
the component in the role of "controller" or "view model".
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
## dash-case
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -260,13 +260,13 @@ the root of filenames (such as `hero-list.component.ts`) are often
|
|||
spelled in dash-case.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## Data binding
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -293,7 +293,7 @@ operations and supporting declaration syntax.
|
|||
* [Two-way data binding with ngModel](guide/template-syntax#ngModel).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -305,7 +305,7 @@ operations and supporting declaration syntax.
|
|||
|
||||
## Decorator | decoration
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -331,24 +331,24 @@ that it decorates. None of the decorations shown here will "leak" to other
|
|||
classes that follow it in the file.
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
Always include parentheses `()` when applying a decorator.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## Dependency injection
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -402,7 +402,7 @@ You can register your own providers.
|
|||
Read more in the [Dependency Injection](guide/dependency-injection) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -414,7 +414,7 @@ Read more in the [Dependency Injection](guide/dependency-injection) page.
|
|||
|
||||
## Directive
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -448,14 +448,14 @@ shaping or reshaping HTML layout, typically by adding, removing, or manipulating
|
|||
elements and their children.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
## ECMAScript
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -474,44 +474,44 @@ to ES5 JavaScript.
|
|||
Angular developers can write in ES5 directly.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## ES2015
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Short hand for [ECMAScript](guide/glossary#ecmascript) 2015.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## ES5
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Short hand for [ECMAScript](guide/glossary#ecmascript) 5, the version of JavaScript run by most modern browsers.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## ES6
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Short hand for [ECMAScript](guide/glossary#ecmascript) 2015.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -527,7 +527,7 @@ Short hand for [ECMAScript](guide/glossary#ecmascript) 2015.
|
|||
|
||||
## Injector
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -536,13 +536,13 @@ that can find a named dependency in its cache or create a dependency
|
|||
with a registered [provider](guide/glossary#provider).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## Input
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -554,13 +554,13 @@ in the template expression to the right of the equal sign.
|
|||
See the [Input and output properties](guide/template-syntax#inputs-outputs) section of the [Template Syntax](guide/template-syntax) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## Interpolation
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -582,7 +582,7 @@ Read more about [interpolation](guide/template-syntax#interpolation) in the
|
|||
[Template Syntax](guide/template-syntax) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -592,7 +592,7 @@ Read more about [interpolation](guide/template-syntax#interpolation) in the
|
|||
|
||||
## Just-in-time (JIT) compilation
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -601,28 +601,28 @@ and launching the application dynamically. Just-in-time mode is a good choice du
|
|||
Consider using the [ahead-of-time](guide/glossary#aot) mode for production apps.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
## kebab-case
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
See [dash-case](guide/glossary#dash-case).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
## Lifecycle hooks
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -649,18 +649,18 @@ Angular calls these hook methods in the following order:
|
|||
Read more in the [Lifecycle Hooks](guide/lifecycle-hooks) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
## Module
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -671,7 +671,7 @@ For details and examples, see the [Angular Modules](guide/ngmodule) page.
|
|||
* ES2015 modules, as described in this section.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -700,7 +700,7 @@ class belongs to a feature module named `date_pipe` in the file `date_pipe.ts`.
|
|||
You rarely access Angular feature modules directly. You usually import them from an Angular [scoped package](guide/glossary#scoped-package) such as `@angular/core`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -710,7 +710,7 @@ You rarely access Angular feature modules directly. You usually import them from
|
|||
|
||||
## Observable
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -722,13 +722,13 @@ To use observables, Angular uses a third-party library called Reactive Extension
|
|||
Observables are a proposed feature for ES2016, the next version of JavaScript.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## Output
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -741,14 +741,14 @@ in the template expression to the right of the equal sign.
|
|||
See the [Input and output properties](guide/template-syntax#inputs-outputs) section of the [Template Syntax](guide/template-syntax) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
## PascalCase
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -759,13 +759,13 @@ This form is also known as *upper camel case* to distinguish it from *lower came
|
|||
In this documentation, "PascalCase" means *upper camel case* and "camelCase" means *lower camel case*.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## Pipe
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -786,13 +786,13 @@ You can also write your own custom pipes.
|
|||
Read more in the page on [pipes](guide/pipes).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## Provider
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -801,7 +801,7 @@ A _provider_ creates a new instance of a dependency for the
|
|||
It relates a lookup token to code—sometimes called a "recipe"—that can create a dependency value.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -811,7 +811,7 @@ It relates a lookup token to code—sometimes called a "recipe"—that c
|
|||
|
||||
## Reactive forms
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -828,13 +828,13 @@ When building reactive forms:
|
|||
Reactive forms are powerful, flexible, and a good choice for more complex data-entry form scenarios, such as dynamic generation of form controls.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## Router
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -858,13 +858,13 @@ directives that users can click to navigate.
|
|||
For more information, see the [Routing & Navigation](guide/router) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## Router module
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -873,13 +873,13 @@ A separate [Angular module](guide/glossary#angular-module) that provides the nec
|
|||
For more information, see the [Routing & Navigation](guide/router) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## Routing component
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -888,14 +888,14 @@ An Angular [component](guide/glossary#component) with a `RouterOutlet` that disp
|
|||
For more information, see the [Routing & Navigation](guide/router) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
## Scoped package
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -916,13 +916,13 @@ is that the scoped package name begins with the Angular *scope name*, `@angular`
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## Service
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -941,7 +941,7 @@ Applications often require services such as a data service or a logging service.
|
|||
For more information, see the [Services](guide/.ial/toh-pt4) page of the [Tour of Heroes](guide/.ial/) tutorial.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -950,7 +950,7 @@ For more information, see the [Services](guide/.ial/toh-pt4) page of the [Tour o
|
|||
|
||||
## snake_case
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -958,7 +958,7 @@ The practice of writing compound words or phrases such that an
|
|||
underscore (`_`) separates one word from the next. This form is also known as *underscore case*.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -970,7 +970,7 @@ underscore (`_`) separates one word from the next. This form is also known as *u
|
|||
|
||||
## Structural directives
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -981,14 +981,14 @@ The `ngIf` "conditional element" directive and the `ngFor` "repeater" directive
|
|||
Read more in the [Structural Directives](guide/structural-directives) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
## Template
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -997,13 +997,13 @@ the support and guidance of an Angular [directive](guide/glossary#directive),
|
|||
most notably a [component](guide/glossary#component).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## Template-driven forms
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1023,13 +1023,13 @@ Read about how to build template-driven forms
|
|||
in the [Forms](guide/forms) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## Template expression
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1041,13 +1041,13 @@ in the [Template expressions](guide/template-syntax#template-expressions) sectio
|
|||
of the [Template Syntax](guide/template-syntax) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## Transpile
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1055,13 +1055,13 @@ The process of transforming code written in one form of JavaScript
|
|||
(such as TypeScript) into another form of JavaScript (such as [ES5](guide/glossary#es5)).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
## TypeScript
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1079,7 +1079,7 @@ you can use other JavaScript dialects such as [ES5](guide/glossary#es5).
|
|||
Read more about TypeScript at [typescriptlang.org](http://www.typescriptlang.org/).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1089,7 +1089,7 @@ Read more about TypeScript at [typescriptlang.org](http://www.typescriptlang.org
|
|||
|
||||
## View
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1106,7 +1106,7 @@ dynamically as the user navigates through the application, typically
|
|||
under the control of a [router](guide/glossary#router).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1122,7 +1122,7 @@ under the control of a [router](guide/glossary#router).
|
|||
|
||||
## Zone
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1145,5 +1145,5 @@ the information it displays via [data bindings](guide/glossary#data-binding).
|
|||
Learn more about zones in this
|
||||
[Brian Ford video](https://www.youtube.com/watch?v=3IqtmUscE_U).
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
|
|
@ -32,7 +32,7 @@ An Angular application is a tree of components. Each component instance has its
|
|||
The tree of components parallels the tree of injectors.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -42,7 +42,7 @@ You won't notice the difference and
|
|||
your mental model should be that every component has its own injector.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -69,7 +69,7 @@ The requests keep bubbling up until Angular finds an injector that can handle th
|
|||
If it runs out of ancestors, Angular throws an error.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -78,7 +78,7 @@ The hunt for providers will climb no higher than the injector for that host comp
|
|||
This is a topic for another day.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -204,7 +204,7 @@ Providing the service at the component level ensures that _every_ instance of th
|
|||
No tax return overwriting. No mess.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -212,7 +212,7 @@ The rest of the scenario code relies on other Angular features and techniques th
|
|||
You can review it and download it from the <live-example></live-example>.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -252,12 +252,12 @@ its injector produces an instance of `Car` resolved by injector (C) with an `Eng
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
The code for this _cars_ scenario is in the `car.components.ts` and `car.services.ts` files of the sample
|
||||
which you can review and download from the <live-example></live-example>.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
|
|
@ -49,7 +49,7 @@ into multiple languages.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -57,7 +57,7 @@ Practitioners of _internationalization_ refer to a translatable text as a "_mess
|
|||
This page uses the words "_text_" and "_message_" interchangably and in the combination, "_text message_".
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -87,7 +87,7 @@ The Angular `i18n` attribute is a marker for translatable content.
|
|||
Place it on every element tag whose fixed text should be translated.
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -96,7 +96,7 @@ It's a custom _attribute_, recognized by Angular tools and compilers.
|
|||
After translation, the compiler removes it.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -251,7 +251,7 @@ Or you could specify the **`other`** category as a catch-all for any unmatched c
|
|||
and write something like: `other {a wolf pack}`.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -263,7 +263,7 @@ which specifies the
|
|||
<a href="http://unicode.org/reports/tr35/tr35-numbers.html#Language_Plural_Rules" target="_blank" title="Pluralization Rules">pluralization rules</a>.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -320,14 +320,14 @@ Open a terminal window at the root of the application project and enter the `ng-
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Windows users may have to quote the command like this: `"./node_modules/.bin/ng-xi18n"`
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -428,14 +428,14 @@ for the project structure to reflect your entire internationalization effort.
|
|||
One approach is to dedicate a folder to localization and store related assets
|
||||
(for example, internationalization files) there.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Localization and internationalization are
|
||||
<a href="https://en.wikipedia.org/wiki/Internationalization_and_localization" target="_blank">different but closely related terms</a>.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -473,7 +473,7 @@ replace the `<target/>` tag with the Spanish greeting:
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -483,7 +483,7 @@ Change either factor and the `id` changes as well.
|
|||
See the **[translation file maintenance discussion](guide/i18n#maintenance)**.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -782,7 +782,7 @@ For this sample, the Spanish language command would be
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -795,7 +795,7 @@ Windows users may have to quote the command:
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -45,7 +45,7 @@ from small, single-purpose parts.
|
|||
After reading the above sections, feel free to skip around among the other pages on this site.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -54,5 +54,5 @@ After reading the above sections, feel free to skip around among the other pages
|
|||
Try the [tutorial](tutorial "Tour of Heroes") if you're ready to start coding or
|
||||
visit the [Architecture](guide/architecture "Basic Concepts") page if you prefer to learn the basic concepts first.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
|
|
@ -475,14 +475,14 @@ The sequence of log messages follows the prescribed hook calling order:
|
|||
`AfterViewInit`, `AfterViewChecked` (3x), and `OnDestroy`.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
The constructor isn't an Angular hook *per se*.
|
||||
The log confirms that input properties (the `name` property in this case) have no assigned values at construction.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -505,7 +505,7 @@ This is the perfect infiltration job for a directive.
|
|||
The heroes will never know they're being watched.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -520,7 +520,7 @@ But you can watch both with a directive.
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -574,7 +574,7 @@ Use `ngOnInit()` for two main reasons:
|
|||
|
||||
Experienced developers agree that components should be cheap and safe to construct.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -583,7 +583,7 @@ Misko Hevery, Angular team lead,
|
|||
you should avoid complex constructor logic.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -601,7 +601,7 @@ Remember also that a directive's data-bound input properties are not set until _
|
|||
That's a problem if you need to initialize the directive based on those properties.
|
||||
They'll have been set when `ngOnInit()` runs.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -609,7 +609,7 @@ The `ngOnChanges()` method is your first opportunity to access those properties.
|
|||
Angular calls `ngOnChanges()` before `ngOnInit()` and many times after that.
|
||||
It only calls `ngOnInit()` once.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -694,13 +694,13 @@ The hero object *reference* didn't change so, from Angular's perspective, there
|
|||
## _DoCheck()_
|
||||
Use the `DoCheck` hook to detect and act upon changes that Angular doesn't catch on its own.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Use this method to detect a change that Angular overlooked.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -821,14 +821,14 @@ The *AfterContent* sample explores the `AfterContentInit()` and `AfterContentChe
|
|||
into the component's template in a designated spot.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
AngularJS developers know this technique as *transclusion*.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -866,7 +866,7 @@ In this case, the projected content is the `<my-child>` from the parent.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -876,7 +876,7 @@ The telltale signs of *content projection* are twofold:
|
|||
* The presence of `<ng-content>` tags in the component's template.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -15,14 +15,14 @@ from the most elementary `@NgModule` to a multi-faceted sample with lazy-loaded
|
|||
|
||||
This page answers the questions many developers ask about NgModule design and implementation.
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
These FAQs assume that you have read the [NgModules](guide/ngmodule) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -76,7 +76,7 @@ General
|
|||
* [Can you summarize the NgModule API?](guide/ngmodule-faq#q-ngmodule-api)
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -92,7 +92,7 @@ Declare these classes in _exactly one_ module of the application.
|
|||
Declare them in _this_ module if they _belong_ to this module.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -107,7 +107,7 @@ you can add to a module's `declarations` list.
|
|||
They're the _only_ classes that you can add to `declarations`.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -130,7 +130,7 @@ For example, don't declare FORMS_DIRECTIVES from `@angular/forms`.
|
|||
strings, numbers, functions, entity models, configurations, business logic, and helper classes.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -153,7 +153,7 @@ Membership in one list doesn't imply membership in another list.
|
|||
as well as dynamically loaded in a pop-up dialog.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -172,7 +172,7 @@ Perhaps you declared "x" in an application sub-module but forgot to export it?
|
|||
The "x" class isn't visible to other modules until you add it to the `exports` list.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -198,7 +198,7 @@ components, directives, and pipes.
|
|||
Import only [BrowserModule](guide/ngmodule-faq#q-browser-vs-common-module) in the root `AppModule`.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -221,20 +221,20 @@ _Do not import_ `BrowserModule` in any other module.
|
|||
*Feature modules* and *lazy-loaded modules* should import `CommonModule` instead.
|
||||
They need the common directives. They don't need to re-install the app-wide providers.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
`BrowserModule` throws an error if you try to lazy load a module that imports it.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
Importing `CommonModule` also frees feature modules for use on _any_ target platform, not just browsers.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -255,7 +255,7 @@ When Angular gets to the 'B' and 'A' in 'D', they're already cached and ready to
|
|||
Angular doesn't like modules with circular references, so don't let Module 'A' import Module 'B', which imports Module 'A'.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -277,7 +277,7 @@ You _can_ re-export entire imported modules, which effectively re-exports all of
|
|||
A module can even export a module that it doesn't import.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -300,7 +300,7 @@ For example, there's no point in re-exporting `HttpModule` because it doesn't ex
|
|||
It's only purpose is to add http service providers to the application as a whole.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -330,7 +330,7 @@ Angular's own `BrowserModule` exports a couple of modules like this:
|
|||
|
||||
A module can export a combination of its own declarations, selected imported classes, and imported modules.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -340,11 +340,11 @@ For example, there's no point in re-exporting `HttpModule` because it doesn't ex
|
|||
It's only purpose is to add http service providers to the application as a whole.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -362,7 +362,7 @@ Apps pass a `Routes` object to `RouterModule.forRoot` in order to configure the
|
|||
You add that result to the `imports` list of the root `AppModule`.
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -370,7 +370,7 @@ Only call and import a `.forRoot` result in the root application module, `AppMod
|
|||
Importing it in any other module, particularly in a lazy-loaded module,
|
||||
is contrary to the intent and will likely produce a runtime error.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -383,7 +383,7 @@ Angular doesn't recognize these names but Angular developers do.
|
|||
Follow this convention when you write similar modules with configurable service providers.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -415,7 +415,7 @@ any class that knows the `HeroService` _type_ can inject that service,
|
|||
not just the classes declared in the `HeroModule`.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -439,7 +439,7 @@ When the router creates a component within the lazy-loaded context,
|
|||
Angular prefers service instances created from these providers to the service instances of the application root injector.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -465,7 +465,7 @@ The service provided by the root `AppModule` takes precedence over services prov
|
|||
The `AppModule` always wins.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -483,7 +483,7 @@ Imported providers are easily replaced by providers from another imported module
|
|||
Such replacement might be by design. It could be unintentional and have adverse consequences.
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -491,7 +491,7 @@ As a general rule, import modules with providers _exactly once_, preferably in t
|
|||
That's also usually the best place to configure, wrap, and override them.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -530,7 +530,7 @@ Alternatively, make the top component a routing host by giving it a `<router-out
|
|||
Define child routes and let the router load module components into that outlet.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -572,7 +572,7 @@ the `HeroComponent` couldn't inject it.
|
|||
The application would fail the moment a user navigated to "Heroes".
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -598,7 +598,7 @@ The changes that editor makes to heroes in its service don't touch the hero inst
|
|||
not the root `AppComponent`.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -635,7 +635,7 @@ than the app-wide singleton version that Angular injected in one of the eagerly
|
|||
|
||||
That's almost certainly a mistake.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -646,11 +646,11 @@ The username goes bonkers as the Angular creates a new `UserService` instance ea
|
|||
<!-- CF: "goes bonkers" is jargon. Can you describe the behavior in plain English? -->
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -682,7 +682,7 @@ It can't added them to the app root injector because that injector is closed to
|
|||
So Angular creates a new child injector for the lazy-loaded module context.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -709,7 +709,7 @@ such as this `CoreModule` constructor from the NgModules page.
|
|||
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -754,7 +754,7 @@ Angular automatically adds the following types of components to the module's `en
|
|||
You don't have to mention these components explicitly, although doing so is harmless.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -775,7 +775,7 @@ There's no need to list a component in both the `bootstrap` and `entryComponent`
|
|||
although doing so is harmless.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -801,7 +801,7 @@ Don't include components that [are referenced](guide/ngmodule-faq#q-template-ref
|
|||
in the templates of other components.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -837,7 +837,7 @@ the compiler omits it.
|
|||
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -851,7 +851,7 @@ Every app is different. Developers have various levels of experience and comfort
|
|||
Some suggestions and guidelines appear to have wide appeal.
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -859,7 +859,7 @@ The following is preliminary guidance based on early experience using NgModules
|
|||
Read with appropriate caution and reflection.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -887,7 +887,7 @@ Never import `CoreModule` in any other module.
|
|||
Consider making `CoreModule` a [pure services module](guide/ngmodule-faq#service-feature-module) with no `declarations`.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -896,7 +896,7 @@ only used within the root `AppComponent` declared by `AppModule`.
|
|||
Someone following this guideline strictly would have declared these components in the `AppModule` instead.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -912,7 +912,7 @@ Feature modules tend to fall into one of the following groups:
|
|||
* [Widget feature modules](guide/ngmodule-faq#widget-feature-module).
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -921,7 +921,7 @@ These guidelines are not laws;
|
|||
follow them unless you have a good reason to do otherwise.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -968,14 +968,14 @@ follow them unless you have a good reason to do otherwise.
|
|||
They might be imported by the root `AppModule` of a small application that lacks routing.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
For an example, see the [Make _Contact_ a feature module](guide/ngmodule#contact-module-v1)
|
||||
section of the [NgModules](guide/ngmodule) page, before routing is introduced.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
</td>
|
||||
|
@ -1059,7 +1059,7 @@ follow them unless you have a good reason to do otherwise.
|
|||
|
||||
The `AppRoutingModule`, `ContactRoutingModule`, and `HeroRoutingModule` are good examples.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1067,7 +1067,7 @@ follow them unless you have a good reason to do otherwise.
|
|||
[Routing & Navigation](guide/router) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
</td>
|
||||
|
@ -1127,13 +1127,13 @@ follow them unless you have a good reason to do otherwise.
|
|||
|
||||
The following table summarizes the key characteristics of each _feature module_ group.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Real-world modules are often hybrids that knowingly deviate from these guidelines.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1311,7 +1311,7 @@ Real-world modules are often hybrids that knowingly deviate from these guideline
|
|||
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1370,7 +1370,7 @@ by adding providers to the `@NgModule.providers` list.
|
|||
<!-- CF: Should this sentence be a bullet point in the list above? -->
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -1378,7 +1378,7 @@ The provided services don't belong to the module nor are they scoped to the decl
|
|||
They are available _everywhere_.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1398,7 +1398,7 @@ Of course you use _JavaScript_ modules to write _Angular_ modules as seen in the
|
|||
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1420,7 +1420,7 @@ Angular only matches selectors and pipe names for classes that are declared by t
|
|||
or exported by a module that this module imports.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1452,7 +1452,7 @@ the Angular compiler incorporates them into compiled component code too.
|
|||
how to link this module with other modules.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -73,7 +73,7 @@ offers answers to specific design and implementation questions.
|
|||
Read this page before reading those FAQs.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -225,7 +225,7 @@ Although the `AppModule` evolves as the app grows, the bootstrap code in `main.t
|
|||
This is the last time you'll look at `main.ts`.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -382,7 +382,7 @@ The initial version of `AppModule` imports `BrowserModule`.
|
|||
Importing `BrowserModule` made all of its public components, directives, and pipes visible
|
||||
to the component templates in `AppModule`.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -393,7 +393,7 @@ More accurately, `NgIf` is declared in `CommonModule` from `@angular/common`.
|
|||
`BrowserModule` imports `CommonModule` and [re-exports](cookbook/ngmodule-faq#q-re-export) it.
|
||||
The net effect is that an importer of `BrowserModule` gets `CommonModule` directives automatically.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -412,7 +412,7 @@ The `ContactComponent` presents a "contact editor,"
|
|||
implemented with Angular forms in the [template-driven form](guide/forms#template-driven) style.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -429,7 +429,7 @@ Modules with components written in the _reactive_ style
|
|||
import the `ReactiveFormsModule`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -506,7 +506,7 @@ Now `[(ngModel)]` binding will work and the user input will be validated by Angu
|
|||
once you declare the new component, pipe, and directive.
|
||||
|
||||
|
||||
~~~ {.alert.is-critical}
|
||||
<div class="alert is-critical">
|
||||
|
||||
|
||||
|
||||
|
@ -519,7 +519,7 @@ Components, directives, and pipes belong to _one module only_.
|
|||
*Never re-declare classes that belong to another module.*
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -540,7 +540,7 @@ Update the `declarations` in the `AppModule` accordingly:
|
|||
{@a import-name-conflict}
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -559,7 +559,7 @@ leaves another issue unresolved.
|
|||
You'll learn more about that issue later in this page, in [Resolve directive conflicts](guide/ngmodule#resolve-conflicts).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -586,7 +586,7 @@ Now you can inject `ContactService` (like `UserService`) into any component in t
|
|||
{@a application-scoped-providers}
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -614,7 +614,7 @@ Now you can inject `ContactService` (like `UserService`) into any component in t
|
|||
of the [NgModule FAQs](cookbook/ngmodule-faq) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -713,7 +713,7 @@ In this case, the contact's `HighlightDirective` makes the application title tex
|
|||
when it should stay gold.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -727,7 +727,7 @@ are not duplicates. Angular keeps both directives and
|
|||
they take turns modifying the same HTML element.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -819,7 +819,7 @@ that concern the contact, and paste them into `ContactModule`.
|
|||
|
||||
You _import_ the `FormsModule` because the contact component needs it.
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -827,7 +827,7 @@ Modules don't inherit access to the components, directives, or pipes that are de
|
|||
What `AppModule` imports is irrelevant to `ContactModule` and vice versa.
|
||||
Before `ContactComponent` can bind with `[(ngModel)]`, its `ContactModule` must import `FormsModule`.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -902,14 +902,14 @@ It has two more modules, one for managing the heroes on staff and another for ma
|
|||
Both modules are in the early stages of development.
|
||||
Their specifics aren't important to the story and this page doesn't discuss every line of code.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Examine and download the complete source for this version from
|
||||
the <live-example plnkr="pre-shared.3" img="devguide/ngmodule/v3-plunker.png">live example.</live-example>
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -941,7 +941,7 @@ The `AppModule` has changed modestly:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -951,7 +951,7 @@ The significant differences will be explained in due course.
|
|||
<!-- CF: Can you be more specific here? Are the differences explained later in this page or in another page? -->
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -993,7 +993,7 @@ The remaining two routes use lazy loading syntax to tell the router where to fin
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1002,7 +1002,7 @@ In this app, the string identifies both the module _file_ and the module _class_
|
|||
the latter separated from the former by a `#`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1023,13 +1023,13 @@ and the dependency-injection providers that produce a configured `Router`.
|
|||
This `AppRoutingModule` is intended for the app _root_ module only.
|
||||
|
||||
|
||||
~~~ {.alert.is-critical}
|
||||
<div class="alert is-critical">
|
||||
|
||||
|
||||
|
||||
Never call `RouterModule.forRoot` in a feature-routing module.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1056,18 +1056,18 @@ This time you pass the route list to the `forChild` method of the `RouterModule`
|
|||
The route list is only responsible for providing additional routes and is intended for feature modules.
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
Always call `RouterModule.forChild` in a feature-routing module.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -1079,7 +1079,7 @@ Angular doesn't recognize them but Angular developers do.
|
|||
that has both shared [declarables](cookbook/ngmodule-faq#q-declarable) and services.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1262,7 +1262,7 @@ It looks like it is supposed to go to a specific question/section within the pag
|
|||
if the `SharedModule` provides the `UserService`.
|
||||
|
||||
|
||||
~~~ {.alert.is-critical}
|
||||
<div class="alert is-critical">
|
||||
|
||||
|
||||
|
||||
|
@ -1270,7 +1270,7 @@ Do *not* specify app-wide singleton `providers` in a shared module.
|
|||
A lazy-loaded module that imports that shared module makes its own copy of the service.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1301,14 +1301,14 @@ Most of this work is familiar. The interesting part is the `CoreModule`.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
You're importing some extra symbols from the Angular core library that you're not using yet.
|
||||
They'll become relevant later in this page.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1322,7 +1322,7 @@ making a singleton instance of the `UserService` available to any component that
|
|||
whether that component is eagerly or lazily loaded.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1352,7 +1352,7 @@ We recommend collecting such single-use classes and hiding their details inside
|
|||
A simplified root `AppModule` imports `CoreModule` in its capacity as orchestrator of the application as a whole.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1409,7 +1409,7 @@ Notice the following:
|
|||
* The new version is leaner and cleaner.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1431,7 +1431,7 @@ a simple object with the following properties:
|
|||
|
||||
The root `AppModule` imports the `CoreModule` and adds the `providers` to the `AppModule` providers.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1439,7 +1439,7 @@ More precisely, Angular accumulates all imported providers before appending the
|
|||
This sequence ensures that whatever you add explicitly to the `AppModule` providers takes precedence
|
||||
over the providers of imported modules.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1473,7 +1473,7 @@ Lastly, call it within the `imports` list of the `AppModule`.
|
|||
The app displays "Miss Marple" as the user instead of the default "Sherlock Holmes".
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -1484,11 +1484,11 @@ is contrary to the intent and can produce a runtime error.
|
|||
Remember to _import_ the result; don't add it to any other `@NgModule` list.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -10,7 +10,7 @@ Recommended npm packages, and how to specify package dependencies.
|
|||
Angular applications and Angular itself depend upon features and functionality provided by a variety of third-party packages.
|
||||
These packages are maintained and installed with the Node Package Manager (<a href="https://docs.npmjs.com/" target="_blank">npm</a>).
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -28,7 +28,7 @@ versions of node and npm. You may need [nvm](https://github.com/creationix/nvm)
|
|||
you already have projects running on your machine that use other versions of node and npm.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -40,13 +40,13 @@ You can use other packages but the packages in _this particular set_ work well t
|
|||
everything you need to build and run the sample applications in this series.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Note: A cookbook or guide page may require an additional library such as *jQuery*.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -136,13 +136,13 @@ Install these polyfills using the npm packages that Angular lists in the *peerDe
|
|||
You must list these packages in the `dependencies` section of your own `package.json`.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
For background on this requirement, see [Why peerDependencies?](guide/npm-packages#why-peer-dependencies).
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -256,7 +256,7 @@ They leave you in control of package and version resolution.
|
|||
It is your responsibility to list all *peer dependency* packages **among your own *devDependencies***.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -267,5 +267,5 @@ The Angular polyfill dependencies are hard requirements. Currently, there is no
|
|||
However, there is an npm feature request for "optional peerDependencies," which would allow you to model this relationship better.
|
||||
When this feature request is implemented, Angular will switch from *peerDependencies* to *optionalPeerDependencies* for all polyfills.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
|
|
@ -55,7 +55,7 @@ Inside the interpolation expression, you flow the component's `birthday` value t
|
|||
function on the right. All pipes work this way.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -70,7 +70,7 @@ Safari and other older browsers don't support it. You can add support with a pol
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -81,7 +81,7 @@ Angular comes with a stock of pipes such as
|
|||
They are all available for use in any template.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -91,7 +91,7 @@ Read more about these and many other built-in pipes in the [pipes topics](api/#!
|
|||
Angular doesn't have a `FilterPipe` or an `OrderByPipe` for reasons explained in the [Appendix](guide/pipes#no-filter-pipe) of this page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -150,7 +150,7 @@ As you click the button, the displayed date alternates between
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -158,7 +158,7 @@ Read more about the `DatePipe` format options in the [Date Pipe](api/common/inde
|
|||
API Reference page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -213,7 +213,7 @@ Your pipe has one such parameter: the `exponent`.
|
|||
Your pipe's name is `exponentialStrength`.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -224,7 +224,7 @@ The `PipeTransform` *interface* defines that method and guides both tooling and
|
|||
Technically, it's optional; Angular looks for and executes the `transform` method regardless.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -248,7 +248,7 @@ Note the following:
|
|||
* You must include your pipe in the `declarations` array of the `AppModule`.
|
||||
|
||||
|
||||
~~~ {.callout.is-helpful}
|
||||
<div class="callout is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -264,7 +264,7 @@ In the previous example, you didn't list the `DatePipe` because all
|
|||
Angular built-in pipes are pre-registered.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -428,7 +428,7 @@ For this reason, a pure pipe is preferable when you can live with the change det
|
|||
When you can't, you *can* use the impure pipe.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -437,7 +437,7 @@ It may be better to pursue the pipe's purpose with a property of the component,
|
|||
a point that's discussed later in this page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -576,7 +576,7 @@ In the previous code sample, the second `fetch` pipe binding demonstrates more p
|
|||
It displays the same hero data in JSON format by chaining through to the built-in `JsonPipe`.
|
||||
|
||||
|
||||
~~~ {.callout.is-helpful}
|
||||
<div class="callout is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -591,7 +591,7 @@ provides an easy way to diagnosis a mysteriously failing data binding or
|
|||
inspect an object for future binding.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -13,7 +13,7 @@ Angular applications are made up of _components_.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -22,7 +22,7 @@ Try it locally with the [***QuickStart seed***](guide/guide/setup "Setup for loc
|
|||
and prepare for development of a real Angular application.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -47,7 +47,7 @@ Interpolation binding is one of many Angular features you'll discover in this do
|
|||
In the example, change the component class's `name` property from `'Angular'` to `'World'` and see what happens.
|
||||
|
||||
|
||||
~~~ {.callout.is-helpful}
|
||||
<div class="callout is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -65,11 +65,11 @@ In the example, change the component class's `name` property from `'Angular'` to
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -77,5 +77,5 @@ In the example, change the component class's `name` property from `'Angular'` to
|
|||
|
||||
Start [**learning Angular**](guide/guide/learning-angular "Learning Angular").
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
|
|
@ -228,7 +228,7 @@ This simple control doesn't have data or validators.
|
|||
In real apps, most form controls have both.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -236,7 +236,7 @@ This guide touches only briefly on `Validators`. For an in-depth look at them,
|
|||
read the [Form Validation](cookbook/form-validation) cookbook.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -261,7 +261,7 @@ you need `[formControl]="name"` in the template on the `<input>`.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -271,7 +271,7 @@ not Angular.
|
|||
It _styles_ the form but in no way impacts the logic of the form.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -416,7 +416,7 @@ in the class. This syntax tells Angular to look for the parent
|
|||
to look for a `FormControl` called `name`.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -428,7 +428,7 @@ but in no way impacts its logic.
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -543,14 +543,14 @@ the second is the required validator, `Validators.required`.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Reactive validators are simple, composable functions.
|
||||
Configuring validation is harder in template-driven forms where you must wrap validators in a directive.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -617,7 +617,7 @@ within the `form` element.
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -629,7 +629,7 @@ They are the Angular directives that bind the HTML controls to the
|
|||
Angular `FormGroup` and `FormControl` properties in the component class.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -637,7 +637,7 @@ The revised template includes more text inputs, a select box for the `state`, ra
|
|||
and a checkbox for the `sidekick`.
|
||||
|
||||
You must bind the option's value property with `[value]="state"`.
|
||||
If you do not bind the value, the select shows the first option form the data model.
|
||||
If you do not bind the value, the select shows the first option from the data model.
|
||||
|
||||
The component _class_ defines control properties without regard for their representation in the template.
|
||||
You define the `state`, `power`, and `sidekick` controls the same way you defined the `name` control.
|
||||
|
@ -1136,7 +1136,7 @@ Replace the _address_ `FormGroup` definition with a _secretLairs_ `FormArray` de
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -1150,7 +1150,7 @@ _Presentation_ requirements often differ from _data_ requirements.
|
|||
The reactive forms approach both emphasizes and facilitates this distinction.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1242,7 +1242,7 @@ Place a button on the form so the user can add a new _secret lair_ and wire it t
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -1254,7 +1254,7 @@ might do something like save the current changes.
|
|||
You do not want to save changes when the user clicks the _Add a Secret Lair_ button.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1370,7 +1370,7 @@ and deep copies of the changed form model values, using the `prepareSaveHero` he
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1384,7 +1384,7 @@ A user's subsequent changes to a lair street would mutate an address street in t
|
|||
The `prepareSaveHero` method makes copies of the form model's `secretLairs` objects so that can't happen.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -181,14 +181,14 @@ Import what you need from it as you would from any other Angular package.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
You'll learn about more options in the [details below](guide/router#browser-url-styles).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -628,7 +628,7 @@ Modern HTML5 browsers were the first to support `pushState` which is why many pe
|
|||
"HTML5 style" URLs.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -638,7 +638,7 @@ learn why HTML5 style is preferred, how to adjust its behavior, and how to switc
|
|||
older hash (#) style, if necessary.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -659,7 +659,7 @@ set the `href` value in **`index.html`** *exactly* as shown here.
|
|||
|
||||
|
||||
|
||||
~~~ {.callout.is-important}
|
||||
<div class="callout is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -683,7 +683,7 @@ That's why the example code replaces the `<base href...>` with a script that wri
|
|||
You only need this trick for the live example, not production code.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -738,7 +738,7 @@ Once the application is bootstrapped, the `Router` performs the initial navigati
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -748,7 +748,7 @@ and create a **[Routing Module](guide/router#routing-module)**, a special type o
|
|||
of routing in feature modules.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -791,7 +791,7 @@ The `RouterOutlet` is a directive from the router library that marks
|
|||
the spot in the template where the router should display the views for that outlet.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -800,7 +800,7 @@ and subsequently inserts the navigated view element
|
|||
immediately _after_ the `<router-outlet>`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -821,14 +821,14 @@ or a URL fragment for jumping to different areas on the page. Query string param
|
|||
are provided through the `[queryParams]` binding which takes an object (e.g. `{ name: 'value' }`), while the URL fragment
|
||||
takes a single value bound to the `[fragment]` input binding.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Learn about the how you can also use the _link parameters array_ in the [appendix below](guide/router#link-parameters-array).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -882,7 +882,7 @@ The router will select _this_ route if it can't match a route earlier in the con
|
|||
A wildcard route can navigate to a custom "404 Not Found" component or [redirect](guide/router#redirect) to an existing route.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -891,7 +891,7 @@ Wildcard routes are the least specific routes in the route configuration.
|
|||
Be sure it is the _last_ route in the configuration.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -974,7 +974,7 @@ In this app, the router should select the route to the `HeroListComponent` only
|
|||
so set the `pathMatch` value to `'full'`.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1002,7 +1002,7 @@ Learn more in Victor Savkin's
|
|||
[post on redirects](http://victorsavkin.com/post/146722301646/angular-router-empty-paths-componentless-routes).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1179,7 +1179,7 @@ then replacing `RouterModule.forRoot` in the `imports` array with the `AppRoutin
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1187,7 +1187,7 @@ Later in this guide you will create [multiple routing modules](guide/router#hero
|
|||
you must import those routing modules [in the correct order](guide/router#routing-module-order).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1344,7 +1344,7 @@ using the same techniques you learned while creating the `AppRoutingModule`.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1356,7 +1356,7 @@ It may seem like overkill early when the feature routes are simple.
|
|||
But routes have a tendency to grow more complex and consistency in patterns pays off over time.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1371,7 +1371,7 @@ In the `AppRoutingModule`, you used the static **`RouterModule.forRoot`** method
|
|||
In a feature module you use the static **`forChild`** method.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1379,7 +1379,7 @@ Only call `RouterModule.forRoot` in the root `AppRoutingModule`
|
|||
(or the `AppModule` if that's where you register top level application routes).
|
||||
In any other module, you must call the **`RouterModule.forChild`** method to register additional routes.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1485,7 +1485,7 @@ The wildcard route — which matches _every_ URL —
|
|||
will intercept the attempt to navigate to a hero route.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1495,7 +1495,7 @@ Learn about inspecting the runtime router configuration
|
|||
[below](guide/router#inspect-config "Inspect the router config").
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1532,7 +1532,7 @@ If a user enters that URL into the browser address bar, the router should recogn
|
|||
pattern and go to the same "Magneta" detail view.
|
||||
|
||||
|
||||
~~~ {.callout.is-helpful}
|
||||
<div class="callout is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -1549,7 +1549,7 @@ the value `15` in the path clearly distinguishes the route to "Magneta" from
|
|||
a route for some other hero.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1621,7 +1621,7 @@ The router composes the destination URL from the array like this:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1632,7 +1632,7 @@ The router extracts the route parameter (`id:15`) from the URL and supplies it t
|
|||
the `HeroDetailComponent` via the `ActivatedRoute` service.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1646,7 +1646,7 @@ The route path and parameters are available through an injected router service c
|
|||
It has a great deal of useful information including:
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1671,7 +1671,7 @@ It has a great deal of useful information including:
|
|||
**`children`**: contains all the [child routes](guide/router#child-routing-component) activated under the current route.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1710,7 +1710,7 @@ Later, in the `ngOnInit` method, you use the `ActivatedRoute` service to retriev
|
|||
pull the hero `id` from the parameters and retrieve the hero to display.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1721,7 +1721,7 @@ so the hero will be retrieved in time to use it.
|
|||
Learn more about the `ngOnInit` method and other component lifecycle hooks in the [Lifecycle Hooks](guide/lifecycle-hooks) guide.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1768,7 +1768,7 @@ You need a way to detect when the route parameters change from _within the same
|
|||
The observable `params` property handles that beautifully.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1783,7 +1783,7 @@ The `Router` destroys a routed component when it is no longer needed and the inj
|
|||
Feel free to unsubscribe anyway. It is harmless and never a bad practice.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1811,7 +1811,7 @@ It's much simpler to write and read:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1821,7 +1821,7 @@ could re-use the component.
|
|||
This sample stays with the observable `params` strategy just in case.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1966,7 +1966,7 @@ They are **separated by semicolons ";"**
|
|||
This is *matrix URL* notation — something you may not have seen before.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1982,7 +1982,7 @@ The syntax may seem strange to you but users are unlikely to notice or care
|
|||
as long as the URL can be emailed and pasted into a browser address bar
|
||||
as this one can.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1994,7 +1994,7 @@ as this one can.
|
|||
The list of heroes is unchanged. No hero row is highlighted.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -2002,7 +2002,7 @@ The <live-example></live-example> *does* highlight the selected
|
|||
row because it demonstrates the final state of the application which includes the steps you're *about* to cover.
|
||||
At the moment this guide is describing the state of affairs *prior* to those steps.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -2048,14 +2048,14 @@ when the user navigates to the component. In `ngOnInit` you subscribe to those v
|
|||
and get the heroes.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
All route/query parameters are strings.
|
||||
The (+) in front of the `params['id']` expression is a JavaScript trick to convert the string to an integer.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -2152,7 +2152,7 @@ The other two `@HostBinding` properties style the display and position of the co
|
|||
The `HeroDetailComponent` will ease in from the left when routed to and will slide down when navigating away.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -2160,7 +2160,7 @@ Applying route animations to individual components works for a simple demo, but
|
|||
it is better to animate routes based on _route paths_.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -2329,7 +2329,7 @@ You can leave *Heroes* in its current state as a contrast with the *Crisis Cente
|
|||
and decide later if the differences are worthwhile.
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -2338,7 +2338,7 @@ In keeping with the
|
|||
changes to the *Crisis Center* won't affect the `AppModule` or
|
||||
any other feature's component.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -2519,7 +2519,7 @@ Navigation _within_ the feature area remains intact even if you change the paren
|
|||
Here's an example:
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -2534,7 +2534,7 @@ If you must navigate to a sibling route, you could use the `../<sibling>` conven
|
|||
one level, then over and down the sibling route path.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -2545,14 +2545,14 @@ After the _link parameters array_, add an object with a `relativeTo` property se
|
|||
The router then calculates the target URL based on the active route's location.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
**Always** specify the complete _absolute_ path when calling router's `navigateByUrl` method.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -2729,7 +2729,7 @@ In this case there is only the "popup" outlet property and its value is another
|
|||
You are in effect saying, _when the user clicks this link, display the component associated with the `compose` route in the `popup` outlet_.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -2746,7 +2746,7 @@ You're not actually doing that here.
|
|||
But to target a named outlet, you must use the richer, more verbose syntax.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -2846,14 +2846,14 @@ A guard's return value controls the router's behavior:
|
|||
* If it returns `false`, the navigation process stops and the user stays put.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
The guard can also tell the router to navigate elsewhere, effectively canceling the current navigation.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -2974,7 +2974,7 @@ feature module, a dashboard route and two unfinished components to manage crises
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -2986,7 +2986,7 @@ Adding an additional binding to the `Dashboard` routerLink,
|
|||
the user navigates to the `/admin` URL and not when navigating to any of the child routes.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -3151,7 +3151,7 @@ Import and add the `LoginRoutingModule` to the `AppModule` imports as well.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -3160,7 +3160,7 @@ the Router access to retrieve these services from the `Injector` during the navi
|
|||
The same rule applies for feature modules loaded [asynchronously](guide/router#asynchronous-routing).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -3262,7 +3262,7 @@ This demo does neither. Instead, it asks the user to make that choice explicitly
|
|||
in a confirmation dialog box that *waits asynchronously for the user's
|
||||
answer*.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -3271,7 +3271,7 @@ The app will be more responsive—and can do other work—by
|
|||
waiting for the user's answer asynchronously. Waiting for the user asynchronously
|
||||
is like waiting for the server asynchronously.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -3561,7 +3561,7 @@ You can use these persistent bits of information for things that need to be prov
|
|||
authentication tokens or session ids.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -3569,7 +3569,7 @@ The `query params` and `fragment` can also be preserved using a `RouterLink` wit
|
|||
the `preserveQueryParams` and `preserveFragment` bindings respectively.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -3631,7 +3631,7 @@ The lazy loading and re-configuration happen just once, when the route is _first
|
|||
the module and routes are available immediately for subsequent requests.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -3639,7 +3639,7 @@ Angular provides a built-in module loader that supports SystemJS to load modules
|
|||
using another bundling tool, such as Webpack, you would use the Webpack mechanism for asynchronously loading modules.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -4082,7 +4082,7 @@ making it the default strategy.
|
|||
You can switch to the `HashLocationStrategy` with an override during the bootstrapping process if you prefer it.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -4090,7 +4090,7 @@ Learn about providers and the bootstrap process in the
|
|||
[Dependency Injection guide](guide/dependency-injection#bootstrap).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -10,14 +10,14 @@ Use an HTTP Client to talk to a remote server.
|
|||
|
||||
[HTTP](https://tools.ietf.org/html/rfc2616) is the primary protocol for browser/server communication.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
The [`WebSocket`](https://tools.ietf.org/html/rfc6455) protocol is another important communication technology;
|
||||
it isn't covered in this page.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -113,7 +113,7 @@ The Angular <code>Http</code> client communicates with the server using a famili
|
|||
The `Http` client is one of a family of services in the Angular HTTP library.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -122,21 +122,21 @@ the Angular HTTP library
|
|||
because the `systemjs.config.js` file maps to that module name.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
Before you can use the `Http` client, you need to register it as a service provider with the dependency injection system.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Read about providers in the [Dependency Injection](guide/dependency-injection) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -155,7 +155,7 @@ The newcomers are the `HttpModule` and the `JsonpModule` from the Angular HTTP l
|
|||
|
||||
To add these modules to the application, pass them to the `imports` array in the root `@NgModule`.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -164,7 +164,7 @@ Though the `JsonpModule` isn't necessary for plain HTTP,
|
|||
there is a JSONP demo later in this page.
|
||||
Loading its module now saves time.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -231,7 +231,7 @@ you **don't** call the service's `get` method in the component's constructor.
|
|||
Instead, call it inside the `ngOnInit` [lifecycle hook](guide/lifecycle-hooks)
|
||||
and rely on Angular to call `ngOnInit` when it instantiates this component.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -239,7 +239,7 @@ This is a *best practice*.
|
|||
Components are easier to test and debug when their constructors are simple, and all real work
|
||||
(especially calling a remote server) is handled in a separate method.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -298,7 +298,7 @@ Look closely at how to call `http.get`:
|
|||
You pass the resource URL to `get` and it calls the server which returns heroes.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -312,7 +312,7 @@ Alternatively, you can temporarily target a JSON file by changing the endpoint U
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -384,7 +384,7 @@ The app must parse that string into JavaScript objects by calling `response.json
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -394,11 +394,11 @@ The Angular HTTP client follows the Fetch specification for the
|
|||
That spec defines a `json()` method that parses the response body into a JavaScript object.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -409,11 +409,11 @@ This is conventional web API behavior, driven by
|
|||
[security concerns](https://www.owasp.org/index.php/OWASP_AJAX_Security_Guidelines#Always_return_JSON_with_an_Object_on_the_outside).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -421,7 +421,7 @@ Make no assumptions about the server API.
|
|||
Not all servers return an object with a `data` property.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -436,7 +436,7 @@ The component that calls the `HeroService` only wants heroes and is kept separat
|
|||
from getting them, the code dealing with where they come from, and the response object.
|
||||
|
||||
|
||||
~~~ {.callout.is-important}
|
||||
<div class="callout is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -452,7 +452,7 @@ which means that the request won't go out until something *subscribes* to the Ob
|
|||
That *something* is the [HeroListComponent](guide/server-communication#subscribe).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -505,7 +505,7 @@ It sets an `errorMessage` variable that's bound conditionally in the `HeroListCo
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -513,7 +513,7 @@ Want to see it fail? In the `HeroService`, reset the api endpoint to a bad value
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
{@a create}
|
||||
{@a update}
|
||||
|
@ -615,14 +615,14 @@ Although the Angular `http` client API returns an `Observable<Response>` you can
|
|||
It's easy to do, and in simple cases, a Promise-based version looks much
|
||||
like the Observable-based version.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
While Promises may be more familiar, Observables have many advantages.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -674,7 +674,7 @@ You have to adjust the calling component to expect a `Promise` instead of an `Ob
|
|||
The only obvious difference is that you call `then()` on the returned Promise instead of `subscribe`.
|
||||
Both methods take the same functional arguments.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -692,7 +692,7 @@ watch [Ben Lesh's talk on Observables](https://www.youtube.com/watch?v=3LKMwkuK0
|
|||
or his video course on [egghead.io](https://egghead.io/lessons/rxjs-rxjs-observables-vs-promises).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -710,7 +710,7 @@ The *origin* is the combination of URI scheme, hostname, and port number.
|
|||
This is called the [same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy).
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -719,20 +719,20 @@ Modern browsers do allow `XHR` requests to servers from a different origin if th
|
|||
If the server requires user credentials, enable them in the [request headers](guide/server-communication#headers).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
Some servers do not support CORS but do support an older, read-only alternative called [JSONP](https://en.wikipedia.org/wiki/JSONP).
|
||||
Wikipedia is one such server.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
This [Stack Overflow answer](http://stackoverflow.com/questions/2067472/what-is-jsonp-all-about/2067584#2067584) covers many details of JSONP.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -777,7 +777,7 @@ The keys are `search`, `action`, `format`, and `callback`.
|
|||
The value of the `search` key is the user-supplied search term to find in Wikipedia.
|
||||
The other three are the fixed values "opensearch", "json", and "JSONP_CALLBACK" respectively.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -785,7 +785,7 @@ The `JSONP` technique requires that you pass a callback function name to the ser
|
|||
The server uses that name to build a JavaScript wrapper function in its response, which Angular ultimately calls to extract the data.
|
||||
All of this happens under the hood.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -838,7 +838,7 @@ the app forwards the Observable result to the template (via `items`) where the `
|
|||
in the `ngFor` handles the subscription. Read more about [async pipes](guide/pipes#async-pipe)
|
||||
in the [Pipes](guide/pipes) page.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -847,7 +847,7 @@ where the component has no need to interact with the data.
|
|||
|
||||
`HeroListComponent` can't use the pipe because `addHero()` pushes newly created heroes into the list.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1034,13 +1034,13 @@ Then it registers the provider in the root `AppModule`.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Remember to include this provider during setup when unit testing the app's HTTP services.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1072,7 +1072,7 @@ It might be wise to keep the `create` request header setting for extra safety.
|
|||
If the app only needed to retrieve data, you could get the heroes from a `heroes.json` file:
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1080,7 +1080,7 @@ You wrap the heroes array in an object with a `data` property for the same reaso
|
|||
to mitigate the [security risk](http://stackoverflow.com/questions/3503102/what-are-top-level-json-arrays-and-why-are-they-a-security-risk)
|
||||
posed by top-level JSON arrays.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1098,7 +1098,7 @@ Because there isn't a real server for this demo,
|
|||
it substitutes the Angular _in-memory web api_ simulator for the actual XHR backend service.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1112,7 +1112,7 @@ See the
|
|||
for configuration options, default behaviors, and limitations.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1156,14 +1156,14 @@ Using standard Angular provider registration techniques, the `InMemoryWebApiModu
|
|||
replaces the default `XHRBackend` service with its own in-memory alternative.
|
||||
At the same time, the `forRoot` method initializes the in-memory web API with the *seed data* from the mock hero dataset.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
The `forRoot()` method name is a strong reminder that you should only call the `InMemoryWebApiModule` _once_,
|
||||
while setting the metadata for the root `AppModule`. Don't call it again.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1176,14 +1176,14 @@ Here is the final, revised version of <code>src/app/app.module.ts</code>, demons
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
Import the `InMemoryWebApiModule` _after_ the `HttpModule` to ensure that
|
||||
the `XHRBackend` provider of the `InMemoryWebApiModule` supersedes all others.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -55,7 +55,7 @@ The HTML `<title>` is in the document `<head>`, outside the body, making it inac
|
|||
We could grab the browser `document` object and set the title manually.
|
||||
That's dirty and undermines our chances of running the app outside of a browser someday.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -65,7 +65,7 @@ inside a Web Worker to improve your app's responsiveness by using multiple threa
|
|||
means that you could run your app inside Electron.js or Windows Universal to deliver it to the desktop.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -48,14 +48,14 @@ Perform the _clone-to-launch_ steps with these terminal commands.
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
`npm start` fails in _Bash for Windows_ which does not support networking to servers as of January, 2017.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -76,14 +76,14 @@ and unzip it into your project folder. Then perform the remaining steps with the
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
`npm start` fails in _Bash for Windows_ which does not support networking to servers as of January, 2017.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -97,14 +97,14 @@ You can quickly delete the _non-essential_ files that concern testing and QuickS
|
|||
(***including all git-related artifacts*** such as the `.git` folder and `.gitignore`!).
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
Do this only in the beginning to avoid accidentally deleting your own tests and git setup!
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -294,7 +294,7 @@ The following are all in `src/`
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -303,7 +303,7 @@ The following are all in `src/`
|
|||
If you're new to Angular, we recommend staying on the [learning path](guide/learning-angular "Angular learning path").
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
<br></br><br></br>
|
||||
|
||||
|
|
|
@ -87,7 +87,7 @@ This guide won't repeat how to _use_ them. But it does explain _how they work_
|
|||
and how to [write your own](guide/structural-directives#unless) structural directive.
|
||||
|
||||
|
||||
~~~ {.callout.is-helpful}
|
||||
<div class="callout is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -109,11 +109,11 @@ The guide refers to the _attribute name_ when describing how
|
|||
you apply the directive to an element in the HTML template.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -132,7 +132,7 @@ You can apply many _attribute_ directives to one host element.
|
|||
You can [only apply one](guide/structural-directives#one-per-element) _structural_ directive to a host element.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -296,7 +296,7 @@ At minimum `NgFor` needs a looping variable (`let hero`) and a list (`heroes`).
|
|||
You enable these features in the string assigned to `ngFor`, which you write in Angular's [microsyntax](guide/structural-directives#microsyntax).
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -305,7 +305,7 @@ Everything _outside_ the `ngFor` string stays with the host element
|
|||
In this example, the `[ngClass]="odd"` stays on the `<div>`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -423,7 +423,7 @@ An `NgSwitchCase` displays its host element when its value matches the switch va
|
|||
The `NgSwitchDefault` displays its host element when no sibling `NgSwitchCase` matches the switch value.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -432,7 +432,7 @@ The `<happy-hero>` is the host element for the happy `*ngSwitchCase`.
|
|||
The `<unknown-hero>` is the host element for the `*ngSwitchDefault`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -732,14 +732,14 @@ The directive consumer expects to bind a true/false condition to `[myUnless]`.
|
|||
That means the directive needs a `myUnless` property, decorated with `@Input`
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Read about `@Input` in the [_Template Syntax_](guide/template-syntax#inputs-outputs) guide.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
File diff suppressed because it is too large
Load Diff
|
@ -68,7 +68,7 @@ The <live-example></live-example>
|
|||
demonstrates all of the syntax and code snippets described in this guide.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -94,7 +94,7 @@ In the following sections, you'll learn how to get and set DOM (Document Object
|
|||
Begin with the first form of data binding—interpolation—to see how much richer template HTML can be.
|
||||
<a href="#toc">back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -156,7 +156,7 @@ Though this is not exactly true. Interpolation is a special syntax that Angular
|
|||
But first, let's take a closer look at template expressions and statements.
|
||||
<a href="#toc">back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -294,7 +294,7 @@ when called twice in a row. If the expression returns an object (including an `a
|
|||
it returns the same object *reference* when called twice in a row.
|
||||
<a href="#toc">back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -380,7 +380,7 @@ Now that you have a feel for template expressions and statements,
|
|||
you're ready to learn about the varieties of data binding syntax beyond interpolation.
|
||||
<a href="#toc">back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -566,7 +566,7 @@ In fact, once you start data binding, you are no longer working with HTML *attri
|
|||
You are setting the *properties* of DOM elements, components, and directives.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -612,7 +612,7 @@ The value of the *property* matters.
|
|||
**The HTML attribute and the DOM property are not the same thing, even when they have the same name.**
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -620,7 +620,7 @@ This fact bears repeating:
|
|||
**Template binding works with *properties* and *events*, not *attributes*.**
|
||||
|
||||
|
||||
~~~ {.callout.is-helpful}
|
||||
<div class="callout is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -635,7 +635,7 @@ When you write a data binding, you're dealing exclusively with properties and ev
|
|||
HTML attributes effectively disappear.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -818,7 +818,7 @@ The following table summarizes:
|
|||
With this broad view in mind, you're ready to look at binding types in detail.
|
||||
<a href="#toc">back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -877,7 +877,7 @@ You cannot use property binding to pull values *out* of the target element.
|
|||
You can't bind to a property of the target element to _read_ it. You can only _set_ it.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -892,7 +892,7 @@ See the API reference for
|
|||
[ContentChild](api/core/index/ContentChild-decorator).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -931,7 +931,7 @@ as it is in the following example:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -940,7 +940,7 @@ one of the property names listed in the directive's `inputs` array or a property
|
|||
Such inputs map to the directive's own properties.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1078,7 +1078,7 @@ content harmlessly.
|
|||
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1094,7 +1094,7 @@ The template syntax provides specialized one-way bindings for scenarios less wel
|
|||
You can set the value of an attribute directly with an **attribute binding**.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1102,7 +1102,7 @@ This is the only exception to the rule that a binding sets a target property.
|
|||
This is the only binding that creates and sets an attribute.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1175,7 +1175,7 @@ is to set ARIA attributes, as in this example:
|
|||
|
||||
<a href="#toc">back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1218,7 +1218,7 @@ It removes the class when the expression is falsy.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1226,11 +1226,11 @@ While this is a fine way to toggle a single class name,
|
|||
the [NgClass directive](guide/template-syntax#ngClass) is usually preferred when managing multiple class names at the same time.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
<a href="#toc">back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1259,7 +1259,7 @@ The following example conditionally sets the font size in “em” and “%”
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1267,11 +1267,11 @@ While this is a fine way to set a single style,
|
|||
the [NgStyle directive](guide/template-syntax#ngStyle) is generally preferred when setting several inline styles at the same time.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1280,11 +1280,11 @@ Note that a _style property_ name can be written in either
|
|||
[camelCase](guide/glossary#camelcase), such as `fontSize`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
<a href="#toc">back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1347,7 +1347,7 @@ of a known directive, as it does in the following example:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1355,7 +1355,7 @@ The `myClick` directive is further described in the section
|
|||
on [aliasing input/output properties](guide/template-syntax#aliasing-io).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1457,7 +1457,7 @@ including queries and saves to a remote server.
|
|||
These changes percolate through the system and are ultimately displayed in this and other views.
|
||||
<a href="#toc">back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1476,7 +1476,7 @@ The `[(x)]` syntax combines the brackets
|
|||
of _property binding_, `[x]`, with the parentheses of _event binding_, `(x)`.
|
||||
|
||||
|
||||
~~~ {.callout.is-important}
|
||||
<div class="callout is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -1489,7 +1489,7 @@ of _property binding_, `[x]`, with the parentheses of _event binding_, `(x)`.
|
|||
Visualize a *banana in a box* to remember that the parentheses go _inside_ the brackets.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1544,7 +1544,7 @@ However, no native HTML element follows the `x` value and `xChange` event patter
|
|||
Fortunately, the Angular [_NgModel_](guide/template-syntax#ngModel) directive is a bridge that enables two-way binding to form elements.
|
||||
<a href="#toc">back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1576,7 +1576,7 @@ This segment reviews some of the most frequently used built-in directives,
|
|||
classified as either [_attribute_ directives](guide/template-syntax#attribute-directives) or [_structural_ directives](guide/template-syntax#structural-directives).
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1599,7 +1599,7 @@ This section is an introduction to the most commonly used attribute directives:
|
|||
* [`NgModel`](guide/template-syntax#ngModel) - two-way data binding to an HTML form element
|
||||
<a href="#toc">back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1648,18 +1648,18 @@ Adding an `ngClass` property binding to `currentClasses` sets the element's clas
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
It's up to you to call `setCurrentClassess()`, both initially and when the dependent properties change.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
<a href="#toc">back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1704,18 +1704,18 @@ Adding an `ngStyle` property binding to `currentStyles` sets the element's style
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
It's up to you to call `setCurrentStyles()`, both initially and when the dependent properties change.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
<a href="#toc">back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1778,7 +1778,7 @@ That `ngModel` directive hides these onerous details behind its own `ngModel` i
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1802,7 +1802,7 @@ to suit Angular's basic [two-way binding syntax](guide/template-syntax#two-way)
|
|||
The [`sizer` shown above](guide/template-syntax#two-way) is an example of this technique.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1848,7 +1848,7 @@ Here are all variations in action, including the uppercase version:
|
|||
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1879,7 +1879,7 @@ _This_ section is an introduction to the common structural directives:
|
|||
* [`NgSwitch`](guide/template-syntax#ngSwitch) - a set of directives that switch among alternative views
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1899,14 +1899,14 @@ Bind the directive to a condition expression like `isActive` in this example.
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-critical}
|
||||
<div class="alert is-critical">
|
||||
|
||||
|
||||
|
||||
Don't forget the asterisk (`*`) in front of `ngIf`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1958,7 +1958,7 @@ The `nullHero` will never be displayed.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1967,11 +1967,11 @@ See also the
|
|||
described below.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
<a href="#toc">back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -2002,14 +2002,14 @@ You can also apply an `NgFor` to a component element, as in this example:
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-critical}
|
||||
<div class="alert is-critical">
|
||||
|
||||
|
||||
|
||||
Don't forget the asterisk (`*`) in front of `ngFor`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -2076,7 +2076,7 @@ The next example captures the `index` in a variable named `i` and displays it wi
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -2084,7 +2084,7 @@ Learn about the other `NgFor` context values such as `last`, `even`,
|
|||
and `odd` in the [NgFor API reference](api/common/index/NgFor-directive).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -2143,7 +2143,7 @@ Here is an illustration of the _trackBy_ effect.
|
|||
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -2202,7 +2202,7 @@ For example, you could replace the `<confused-hero>` switch case with the follow
|
|||
|
||||
<a href="#toc">back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -2294,7 +2294,7 @@ This example declares the `fax` variable as `ref-fax` instead of `#fax`.
|
|||
|
||||
<a href="#toc">back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -2312,18 +2312,18 @@ properties on the *left side of the binding declaration*.
|
|||
These directive properties must be declared as **inputs** or **outputs**.
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
Remember: All **components** are **directives**.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -2342,7 +2342,7 @@ You have *limited* access to members of a **target** directive.
|
|||
You can only bind to properties that are explicitly identified as *inputs* and *outputs*.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -2386,7 +2386,7 @@ In the `HeroDetailComponent`, such properties are marked as input or output prop
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -2404,7 +2404,7 @@ You can specify an input/output property either with a decorator or in a metadat
|
|||
Don't do both!
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -2467,7 +2467,7 @@ You can specify the alias for the property name by passing it into the input/out
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -2482,11 +2482,11 @@ the directive property name on the *left* and the public alias on the *right*:
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
<a href="#toc">back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -2560,7 +2560,7 @@ The generated output would look something like this
|
|||
|
||||
<a href="#toc">back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -2664,7 +2664,7 @@ The display is blank, but the app keeps rolling without errors.
|
|||
It works perfectly with long property paths such as `a?.b?.c?.d`.
|
||||
<a href="#toc">back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -141,7 +141,7 @@ The sample application and all tests in this guide are available as live example
|
|||
* <live-example plnkr="app-specs" embedded-style>All specs that test the sample application</live-example>.
|
||||
* <live-example plnkr="bag-specs" embedded-style>A grab bag of additional specs</live-example>.<a href="#top" class='to-top'>Back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -321,7 +321,7 @@ But first you should write a dummy test to verify that your test environment is
|
|||
and to lock in a few basic testing skills.
|
||||
<a href="#top" class='to-top'>Back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -335,7 +335,7 @@ Start with a simple test to make sure that the setup works properly.
|
|||
Create a new file called `1st.spec.ts` in the application root folder, `src/app/`
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -344,7 +344,7 @@ Tests written in Jasmine are called _specs_ .
|
|||
the convention adhered to by `karma.conf.js` and other tooling.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -375,14 +375,14 @@ Compile and run it in karma from the command line using the following command:
|
|||
The command compiles the application and test code and starts karma.
|
||||
Both processes watch pertinent files, write messages to the console, and re-run when they detect changes.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
The documentation setup defines the `test` command in the `scripts` section of npm's `package.json`.
|
||||
The Angular CLI has different commands to do the same thing. Adjust accordingly.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -444,7 +444,7 @@ Restore the expectation from `false` back to `true`.
|
|||
Both processes detect the change, re-run, and karma reports complete success.
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -452,7 +452,7 @@ The console log can be quite long. Keep your eye on the last line.
|
|||
When all is well, it reads `SUCCESS`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -487,7 +487,7 @@ You can also try this test as a <live-example plnkr="1st-specs" title="First spe
|
|||
All of the tests in this guide are available as [live examples](guide/testing#live-examples "Live examples of these tests").
|
||||
<a href="#top" class='to-top'>Back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -561,14 +561,14 @@ The base state includes a default testing module configuration consisting of the
|
|||
declarables (components, directives, and pipes) and providers (some of them mocked)
|
||||
that almost everyone needs.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
The testing shims mentioned [later](guide/testing#testbed-methods) initialize the testing module configuration
|
||||
to something like the `BrowserModule` from `@angular/platform-browser`.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -588,14 +588,14 @@ In this example, `TestBed.createComponent` creates an instance of `BannerCompone
|
|||
returns a [_component test fixture_](guide/testing#component-fixture).
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
Do not re-configure `TestBed` after calling `createComponent`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -620,7 +620,7 @@ The **`query`** method takes a predicate function and searches the fixture's ent
|
|||
_first_ element that satisfies the predicate.
|
||||
The result is a _different_ `DebugElement`, one associated with the matching DOM element.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -630,7 +630,7 @@ A _predicate_ is a function that returns a boolean.
|
|||
A query predicate receives a `DebugElement` and returns `true` if the element meets the selection criteria.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -740,7 +740,7 @@ But a direct, synchronous update of the component property is invisible.
|
|||
The test must call `fixture.detectChanges()` manually to trigger another cycle of change detection.
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -749,11 +749,11 @@ the samples in this guide _always call_ `detectChanges()` _explicitly_.
|
|||
There is no harm in calling `detectChanges()` more often than is strictly necessary.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
<a href="#top" class='to-top'>Back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -832,14 +832,14 @@ In this example, the `BannerComponent` is the only component to compile.
|
|||
When `compileComponents` completes, the external templates and css files have been "inlined"
|
||||
and `TestBed.createComponent` can create new instances of `BannerComponent` synchronously.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
WebPack developers need not call `compileComponents` because it inlines templates and css
|
||||
as part of the automated build process that precedes running the test.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -850,7 +850,7 @@ Any of these components might have external templates and css files.
|
|||
`TestBed.compileComponents` compiles all of the declared components asynchronously at one time.
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -858,7 +858,7 @@ Do not configure the `TestBed` after calling `compileComponents`.
|
|||
Make `compileComponents` the last step
|
||||
before calling `TestBed.createComponent` to instantiate the _component-under-test_.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -903,7 +903,7 @@ The two `beforeEach` calls are widely preferred.
|
|||
Take a moment to explore this component spec as a <live-example plnkr="banner-specs" title="Spec for component with external template" embedded-style></live-example>.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -916,11 +916,11 @@ in case you decide later to re-factor the template into a separate file.
|
|||
The tests in this guide only call `compileComponents` when necessary.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
<a href="#top" class='to-top'>Back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1015,7 +1015,7 @@ so it is safe to call `TestBed.get` as follows:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1026,7 +1026,7 @@ see the section [_Override a component's providers_](guide/testing#component-ove
|
|||
explains why you must get the service from the component's injector instead.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1068,7 +1068,7 @@ And here are some tests:
|
|||
|
||||
The first is a sanity test; it confirms that the stubbed `UserService` is called and working.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1077,7 +1077,7 @@ If the expectation fails, Jasmine displays this addendum after the expectation f
|
|||
In a spec with multiple expectations, it can help clarify what went wrong and which expectation failed.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1086,7 +1086,7 @@ The second test validates the effect of changing the user name.
|
|||
The third test checks that the component displays the proper message when there is no logged-in user.
|
||||
<a href="#top" class='to-top'>Back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1140,7 +1140,7 @@ The spy is designed such that any call to `getQuote` receives an immediately res
|
|||
The spy bypasses the actual `getQuote` method and therefore does not contact the server.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1152,7 +1152,7 @@ Spying on the real service isn't always easy, especially when the real service h
|
|||
You can _stub and spy_ at the same time, as shown in [an example below](guide/testing#spy-stub).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1200,14 +1200,14 @@ as [discussed earlier](guide/testing#async-in-before-each) when it was called in
|
|||
Although `async` does a great job of hiding asynchronous boilerplate,
|
||||
some functions called within a test (such as `fixture.whenStable`) continue to reveal their asynchronous behavior.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
The `fakeAsync` alternative, [covered below](guide/testing#fake-async), removes this artifact and affords a more linear coding experience.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1263,14 +1263,14 @@ There is no `then(...)` to disrupt the visible flow of control.
|
|||
The promise-returning `fixture.whenStable` is gone, replaced by `tick()`.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
There _are_ limitations. For example, you cannot make an XHR call from within a `fakeAsync`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1322,7 +1322,7 @@ code that involves the `intervalTimer`, as is common when
|
|||
testing async `Observable` methods.
|
||||
<a href="#top" class='to-top'>Back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1379,13 +1379,13 @@ The `DashboardComponent` depends on the Angular router and the `HeroService`.
|
|||
You'd probably have to replace them both with test doubles, which is a lot of work.
|
||||
The router seems particularly challenging.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
The [discussion below](guide/testing#routed-component) covers testing components that require the router.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1434,7 +1434,7 @@ the test must match the element value with the uppercased name:
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -1444,7 +1444,7 @@ representation—something not possible with
|
|||
low cost and without resorting to much slower and more complicated end-to-end tests.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1513,7 +1513,7 @@ custom event object as the second parameter. The default is a (partial)
|
|||
accepted by many handlers including the `RouterLink` directive.
|
||||
|
||||
|
||||
~~~ {.callout.is-critical}
|
||||
<div class="callout is-critical">
|
||||
|
||||
|
||||
|
||||
|
@ -1528,7 +1528,7 @@ It's a function defined in _this guide's sample code_.
|
|||
All of the sample tests use it.
|
||||
If you like it, add it to your own collection of helpers.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1540,7 +1540,7 @@ Here's the previous test, rewritten using this click helper.
|
|||
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1602,7 +1602,7 @@ Only the selected event test differs. It confirms that the selected `DashboardHe
|
|||
really does find its way up through the event binding to the host component.
|
||||
<a href="#top" class='to-top'>Back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1680,7 +1680,7 @@ The `inject` function has two parameters:
|
|||
1. A test function whose parameters correspond exactly to each item in the injection token array.
|
||||
|
||||
|
||||
~~~ {.callout.is-important}
|
||||
<div class="callout is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -1694,7 +1694,7 @@ The `inject` function uses the current `TestBed` injector and can only return se
|
|||
It does not return services from component providers.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1709,14 +1709,14 @@ If you need a service provided by the component's _own_ injector, call `fixture
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
Use the component's own injector to get the service actually injected into the component.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1725,14 +1725,14 @@ You cannot call any more `TestBed` configuration methods, not `configureTestingM
|
|||
nor any of the `override...` methods. The `TestBed` throws an error if you try.
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
Do not configure the `TestBed` after calling `inject`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1764,7 +1764,7 @@ Here's the `HeroDetailComponent` constructor:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1778,7 +1778,7 @@ If the`id` parameter is missing, the `pluck` operator fails and the `catch` trea
|
|||
|
||||
The [Router](guide/router#route-parameters) guide covers `ActivatedRoute.params` in more detail.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1821,24 +1821,24 @@ drives the stub's `params` _Observable_ and returns the same value to every `par
|
|||
|
||||
* Setting the `testParams` property also updates the stub's internal value for the `snapshot` property to return.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
The [_snapshot_](guide/router#snapshot "Router guide: snapshot") is another popular way for components to consume route parameters.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
~~~ {.callout.is-helpful}
|
||||
<div class="callout is-helpful">
|
||||
|
||||
|
||||
|
||||
The router stubs in this guide are meant to inspire you. Create your own stubs to fit your testing needs.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1854,14 +1854,14 @@ Here's a test demonstrating the component's behavior when the observed `id` refe
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
The `createComponent` method and `page` object are discussed [in the next section](guide/testing#page-object).
|
||||
Rely on your intuition for now.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1891,18 +1891,18 @@ New heroes have `id=0` and a blank `name`. This test confirms that the component
|
|||
|
||||
|
||||
|
||||
~~~ {.callout.is-helpful}
|
||||
<div class="callout is-helpful">
|
||||
|
||||
|
||||
|
||||
Inspect and download _all_ of the guide's application test code with this <live-example plnkr="app-specs" embedded-style>live example</live-example>.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
<a href="#top" class='to-top'>Back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -1968,7 +1968,7 @@ Here are a few more `HeroDetailComponent` tests to drive the point home.
|
|||
|
||||
<a href="#top" class='to-top'>Back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -2040,7 +2040,7 @@ Try a test configuration that imports the `HeroModule` like this one:
|
|||
|
||||
That's _really_ crisp. Only the _test doubles_ in the `providers` remain. Even the `HeroDetailComponent` declaration is gone.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -2048,24 +2048,24 @@ In fact, if you try to declare it, Angular throws an error because
|
|||
`HeroDetailComponent` is declared in both the `HeroModule` and the `DynamicTestModule` (the testing module).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
Importing the component's feature module is often the easiest way to configure the tests,
|
||||
especially when the feature module is small and mostly self-contained, as feature modules should be.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
<a href="#top" class='to-top'>Back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -2093,7 +2093,7 @@ And `TestBed.configureTestingModule` can't configure them either.
|
|||
Angular has been creating new instances of the real `HeroDetailService` all along!
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -2113,7 +2113,7 @@ The [previous test configuration](guide/testing#feature-module-import) replaces
|
|||
that intercepts server requests and fakes their responses.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -2224,7 +2224,7 @@ for digging into and replacing parts of these other classes.
|
|||
Explore the options and combinations on your own.
|
||||
<a href="#top" class='to-top'>Back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -2341,7 +2341,7 @@ Here are some tests that leverage this setup:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -2357,7 +2357,7 @@ This is a skill you may need to test a more sophisticated component, one that ch
|
|||
re-calculates parameters, or re-arranges navigation options when the user clicks the link.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -2380,7 +2380,7 @@ A _different_ battery of tests can explore whether the application navigates as
|
|||
in the presence of conditions that influence guards such as whether the user is authenticated and authorized.
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -2388,11 +2388,11 @@ A future guide update will explain how to write such
|
|||
tests with the `RouterTestingModule`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
<a href="#top" class='to-top'>Back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -2434,7 +2434,7 @@ that contributes actively to the tests.
|
|||
The [tests in this example](guide/testing#app-component-tests) are unchanged.
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -2443,11 +2443,11 @@ However, the compiler no longer alerts you to mistakes
|
|||
such as misspelled or misused components and directives.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
<a href="#top" class='to-top'>Back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -2510,14 +2510,14 @@ A better solution is to create an artificial test component that demonstrates al
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
The `<input>` case binds the `HighlightDirective` to the name of a color value in the input box.
|
||||
The initial value is the word "cyan" which should be the background color of the input box.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -2547,7 +2547,7 @@ and its `defaultColor`.
|
|||
* `DebugElement.properties` affords access to the artificial custom property that is set by the directive.
|
||||
<a href="#top" class='to-top'>Back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -2576,7 +2576,7 @@ They follow patterns familiar to test developers everywhere:
|
|||
* Substitute test doubles (stubs, spys, and mocks) for the real dependencies.
|
||||
|
||||
|
||||
~~~ {.callout.is-important}
|
||||
<div class="callout is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -2592,7 +2592,7 @@ Write _Angular_ tests to validate the part as it interacts with Angular,
|
|||
updates the DOM, and collaborates with the rest of the application.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -2775,7 +2775,7 @@ properly bound to its template or even data bound at all.
|
|||
Use Angular tests for that.
|
||||
<a href="#top" class='to-top'>Back to top</a>
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -2849,7 +2849,7 @@ Here's a summary of the stand-alone functions, in order of likely utility:
|
|||
by flushing both _timer_ and _micro-task_ queues within the _fakeAsync test zone_.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -2857,7 +2857,7 @@ Here's a summary of the stand-alone functions, in order of likely utility:
|
|||
"<a href="https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/"
|
||||
target="_blank">_Tasks, microtasks, queues and schedules_</a>".
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -2963,7 +2963,7 @@ Here's a summary of the stand-alone functions, in order of likely utility:
|
|||
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
@ -3603,7 +3603,7 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
|
|||
The immediate `DebugElement` children. Walk the tree by descending through `children`.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -3611,7 +3611,7 @@ Here are the most useful `DebugElement` members for testers, in approximate orde
|
|||
`DebugElement` derives from `DebugNode` objects and there are often
|
||||
more nodes than elements. Testers can usually ignore plain nodes.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
</td>
|
||||
|
@ -3779,7 +3779,7 @@ The CLI delivers similar files with the same purpose.
|
|||
|
||||
Here's a brief description of this guide's setup files:
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -3787,7 +3787,7 @@ The deep details of these files and how to reconfigure them for your needs
|
|||
is a topic beyond the scope of this guide .
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -3943,7 +3943,7 @@ as the application source code files that they test:
|
|||
* When you rename the source file (inevitable), you remember to rename the test file.
|
||||
|
||||
|
||||
---
|
||||
<hr/>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -125,14 +125,14 @@ When you want to make something available to other modules, you `export` it.
|
|||
_ES5_ lacks native support for modules.
|
||||
In an Angular _ES5_ application, you load each file manually by adding a `<script>` tag to `index.html`.
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
The order of `<script>` tags is often significant.
|
||||
You must load a file that defines a public JavaScript entity before a file that references that entity.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -200,7 +200,7 @@ In _ES5_ you use the shared namespace object to access "exported" entities from
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -211,7 +211,7 @@ Then use `module.exports` and `require` to export and import application code.
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -375,7 +375,7 @@ next to the original _ES5_ version for comparison:
|
|||
|
||||
|
||||
|
||||
~~~ {.callout.is-helpful}
|
||||
<div class="callout is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -391,7 +391,7 @@ An **unnamed** constructor displays as an anonymous function (e.g., `class0`)
|
|||
which is impossible to find in the source code.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -702,7 +702,7 @@ array as before. Use a nested array to define a parameter's complete injection s
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -712,7 +712,7 @@ With `Optional`, Angular sets the constructor parameter to `null`
|
|||
and the component displays the title without a prefix.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -801,7 +801,7 @@ These particular _TypeScript_ and _ES6_ code snippets happen to be identical.
|
|||
Several _property_ decorators query a component's nested view and content components.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -810,7 +810,7 @@ _View_ children are associated with element tags that appear _within_ the compon
|
|||
_Content_ children are associated with elements that appear _between_ the component's element tags;
|
||||
they are projected into an `<ng-content>` slot in the component's template.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -879,7 +879,7 @@ They can be added in the same way as [`@ViewChild`](api/core/index/ViewChild-dec
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -887,7 +887,7 @@ In _TypeScript_ and _ES6-with-decorators_ you can also use the `queries` metadat
|
|||
instead of the `@ViewChild` and `@ContentChild` property decorators.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -28,14 +28,14 @@ that are important to Angular developers, including details about the following
|
|||
Typically, you add a TypeScript configuration file called `tsconfig.json` to your project to
|
||||
guide the compiler as it generates JavaScript files.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
For details about `tsconfig.json`, see the official
|
||||
[TypeScript wiki](http://www.typescriptlang.org/docs/handbook/tsconfig-json.html).
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -477,14 +477,14 @@ We will import `UpgradeModule` inside our Angular module, and then use it for
|
|||
bootstrapping our AngularJS module. Let's see how.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Learn more about Angular modules at the [NgModule guide](guide/ngmodule).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -613,14 +613,14 @@ Angular module.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
All Angular components, directives and pipes must be declared in an NgModule.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -634,7 +634,7 @@ use like any other directive in our AngularJS templates.
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -644,7 +644,7 @@ An AngularJS element directive is matched based on its _name_.
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -682,7 +682,7 @@ attribute syntax to bind the inputs and outputs**. This is a requirement for dow
|
|||
components. The expressions themselves are still regular AngularJS expressions.
|
||||
|
||||
|
||||
~~~ {.callout.is-important}
|
||||
<div class="callout is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -711,7 +711,7 @@ But when using them from AngularJS templates, we need to use kebab-case:
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -781,7 +781,7 @@ All that is left is to add it to `AppModule`'s `declarations` array.
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -791,7 +791,7 @@ component is just a directive - a tag - and Angular doesn't have to concern itse
|
|||
it's children.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -968,7 +968,7 @@ of the `<ng-content>` tag in Angular:
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -976,7 +976,7 @@ When AngularJS content gets projected inside an Angular component, it still
|
|||
remains in "AngularJS land" and is managed by the AngularJS framework.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1003,7 +1003,7 @@ point:
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -1012,7 +1012,7 @@ It is on by default for component directives defined with the
|
|||
1.5 component API.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1076,7 +1076,7 @@ We can then inject it in Angular using it's class as a type annotation:
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -1087,7 +1087,7 @@ checking. This is not required though, and any AngularJS service, factory, or
|
|||
provider can be upgraded.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1161,7 +1161,7 @@ Module Factory:
|
|||
And that's all we need to get the full benefit of AoT for Angular apps!
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -1170,7 +1170,7 @@ so in order for upgraded components to work we needs to implement the lifecycle
|
|||
on the upgraded component class and forward them to the `UpgradeComponent` parent.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1539,7 +1539,7 @@ can verify we're calling their APIs with the correct kinds of arguments.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1555,7 +1555,7 @@ does not yet have type annotations. We could use it as a guide to inform
|
|||
us about how close we are to having a fully annotated project.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1618,11 +1618,11 @@ By the time we're done, we'll be able to remove AngularJS from the project
|
|||
completely, but the key is to do this piece by piece without breaking the application.
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
The project also contains some animations, which we are not yet upgrading in this version of the guide. This will change in a later release.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1756,7 +1756,7 @@ exciting! We're not running any actual Angular components yet though,
|
|||
so let's do that next.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1779,7 +1779,7 @@ Instead we declare `angular` as `angular.IAngularStatic` to indicate it is a glo
|
|||
and still have full typing support.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1908,7 +1908,7 @@ In any case, what we've achieved is a migration of a service to Angular
|
|||
without having to yet migrate the components that use it.
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -1917,7 +1917,7 @@ Observables into Promises in the service. This can in many cases further
|
|||
reduce the amount of changes needed in the component controllers.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -2260,14 +2260,14 @@ and let that directive construct the appropriate URL to the `PhoneDetailComponen
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
See the [Routing](guide/router) page for details.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -103,7 +103,7 @@ Here's what the UI displays:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -117,7 +117,7 @@ for `event.target.value` in which case the same user input would produce:
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -186,7 +186,7 @@ Type something in the input box, and watch the display update with each keystrok
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -199,7 +199,7 @@ to the number 0, the shortest template statement possible.
|
|||
While the statement does nothing useful,
|
||||
it satisfies Angular's requirement so that Angular will update the screen.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -12,7 +12,7 @@ Some developers prefer Visual Studio as their Integrated Development Environment
|
|||
This cookbook describes the steps required to set up and use the
|
||||
Angular QuickStart files in **Visual Studio 2015 within an ASP.NET 4.x project**.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -20,7 +20,7 @@ There is no *live example* for this cookbook because it describes Visual Studio,
|
|||
the QuickStart application itself.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
{@a asp-net-4}
|
||||
|
@ -42,7 +42,7 @@ Visual Studio 2015, follow these steps:
|
|||
* [Step 5](guide/visual-studio-2015#build-and-run): Build and run the app.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -52,7 +52,7 @@ then consider the _experimental_
|
|||
Note that the resulting code does not map to the docs. Adjust accordingly.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -66,7 +66,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.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -75,7 +75,7 @@ by running `node -v` and `npm -v` in a terminal window.
|
|||
Older versions produce errors.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -163,7 +163,7 @@ Create the ASP.NET 4.x project in the usual way as follows:
|
|||
* Select the desired ASP.NET 4.5.2 template and click OK.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -171,7 +171,7 @@ This cookbook uses the `Empty` template with no added folders,
|
|||
no authentication, and no hosting. Pick the template and options appropriate for your project.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -238,7 +238,7 @@ instead of `node_modules` without the slash.
|
|||
change the npm `path` to `/node_modules/` with a slash.
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -246,7 +246,7 @@ After these changes, `npm start` no longer works.
|
|||
You must choose to configure _either_ for F5 with IIS _or_ for `npm start` with the lite-server.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -298,7 +298,7 @@ rewrite rules near the bottom of the `web.config`:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -309,20 +309,20 @@ The URL in `<action type="Rewrite" url="/src/"/>` should
|
|||
match the base href in `index.html`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
Build and launch the app with debugger by clicking the **Run** button or by pressing `F5`.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
It's faster to run without the debugger by pressing `Ctrl-F5`.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -156,7 +156,7 @@ and emits *two* bundle files, one called `app.js` containing only the applicatio
|
|||
another called `vendor.js` with all the vendor dependencies.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -164,7 +164,7 @@ The `[name]` in the output name is a *placeholder* that a Webpack plugin replace
|
|||
`app` and `vendor`. Plugins are [covered later](guide/webpack#commons-chunk-plugin) in the guide.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -309,7 +309,7 @@ Add these files:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -321,7 +321,7 @@ Webpack, the plugins, and the loaders are also installed as packages.
|
|||
They are listed in the updated `packages.json`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -353,7 +353,7 @@ Add a `polyfills.ts` like this one to the `src/` folder.
|
|||
|
||||
|
||||
|
||||
~~~ {.callout.is-critical}
|
||||
<div class="callout is-critical">
|
||||
|
||||
|
||||
|
||||
|
@ -366,7 +366,7 @@ Add a `polyfills.ts` like this one to the `src/` folder.
|
|||
Load `zone.js` early within `polyfills.ts`, immediately after the other ES6 and metadata shims.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -459,7 +459,7 @@ Tell Webpack to resolve extension-less file requests by looking for matching fil
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -467,7 +467,7 @@ If Webpack should resolve extension-less files for styles and HTML,
|
|||
add `.css` and `.html` to the list.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -493,7 +493,7 @@ Rules tell Webpack which loaders to use for each file, or module:
|
|||
* CSS—the first pattern matches application-wide styles; the second handles
|
||||
component-scoped styles (the ones specified in a component's `styleUrls` metadata property).
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -505,18 +505,18 @@ The second pattern filters for component-scoped styles and loads them as strings
|
|||
which is what Angular expects to do with styles specified in a `styleUrls` metadata property.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Multiple loaders can be chained using the array notation.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -546,7 +546,7 @@ Of course the application code imports vendor code.
|
|||
On its own, Webpack is not smart enough to keep the vendor code out of the `app.js` bundle.
|
||||
The `CommonsChunkPlugin` does that job.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -555,7 +555,7 @@ Where Webpack finds that `app` has shared dependencies with `vendor`, it removes
|
|||
It would remove `polyfills` from `vendor` if they shared dependencies, which they don't.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -119,14 +119,14 @@ These interpolation bindings present the component's `title` and `hero` property
|
|||
as strings, inside the HTML header tags.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Read more about interpolation in the [Displaying Data](guide/displaying-data) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -231,7 +231,7 @@ The updated `AppModule` looks like this:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -242,7 +242,7 @@ Read more about `FormsModule` and `ngModel` in the
|
|||
[Template Syntax](guide/template-syntax) guide.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -123,7 +123,7 @@ Create a public property in `AppComponent` that exposes the heroes for binding.
|
|||
The `heroes` type isn't defined because TypeScript infers it from the `HEROES` array.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -131,7 +131,7 @@ The hero data is separated from the class implementation
|
|||
because ultimately the hero names will come from a data service.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -163,7 +163,7 @@ Modify the `<li>` tag by adding the built-in directive `*ngFor`.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -185,7 +185,7 @@ Read more about `ngFor` and template input variables in the
|
|||
[Template Syntax](guide/template-syntax) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -259,7 +259,7 @@ The `onSelect(hero)` expression calls the `AppComponent` method, `onSelect()`,
|
|||
passing the template input variable `hero`, as an argument.
|
||||
That's the same `hero` variable you defined previously in the `ngFor` directive.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -269,7 +269,7 @@ Learn more about event binding at the
|
|||
[Template Syntax](guide/template-syntax) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -334,14 +334,14 @@ Then add the `ngIf` built-in directive and set it to the `selectedHero` property
|
|||
|
||||
|
||||
|
||||
~~~ {.alert.is-critical}
|
||||
<div class="alert is-critical">
|
||||
|
||||
|
||||
|
||||
Don't forget the asterisk (`*`) in front of `ngIf`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -355,7 +355,7 @@ When the user picks a hero, `selectedHero` becomes defined and
|
|||
`ngIf` puts the hero detail content into the DOM and evaluates the nested bindings.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -366,7 +366,7 @@ Read more about `ngIf` and `ngFor` in the
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -399,14 +399,14 @@ When the expression is `false`, Angular removes the `selected` class.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Read more about the `[class]` binding in the [Template Syntax](guide/template-syntax#ngClass "Template syntax: NgClass") guide.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -205,7 +205,7 @@ preceding it with the `@Input` decorator that you imported earlier.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -213,7 +213,7 @@ Read more about _input_ properties in the
|
|||
[Attribute Directives](guide/attribute-directives#why-input) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -260,14 +260,14 @@ In general, the `declarations` array contains a list of application components,
|
|||
A component must be declared in a module before other components can reference it.
|
||||
This module declares only the two application components, `AppComponent` and `HeroDetailComponent`.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Read more about Angular modules in the [NgModules](guide/ngmodule "Angular Modules (NgModule) guide.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -120,7 +120,7 @@ share that service with all components that need the data.
|
|||
### Create the HeroService
|
||||
Create a file in the `app` folder called `hero.service.ts`.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -128,7 +128,7 @@ The naming convention for service files is the service name in lowercase followe
|
|||
For a multi-word service name, use lower [dash-case](guide/glossary#!).
|
||||
For example, the filename for `SpecialSuperHeroService` is `special-super-hero.service.ts`.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -144,13 +144,13 @@ Name the class `HeroService` and export it for others to import.
|
|||
### Injectable services
|
||||
Notice that you imported the Angular `Injectable` function and applied that function as an `@Injectable()` decorator.
|
||||
|
||||
~~~ {.callout.is-helpful}
|
||||
<div class="callout is-helpful">
|
||||
|
||||
|
||||
|
||||
Don't forget the parentheses. Omitting them leads to an error that's difficult to diagnose.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -267,13 +267,13 @@ defines a private `heroService` property and identifies it as a `HeroService` in
|
|||
Now Angular knows to supply an instance of the `HeroService` when it creates an `AppComponent`.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Read more about dependency injection in the [Dependency Injection](guide/dependency-injection) page.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -338,13 +338,13 @@ at creation, after each change, and at its eventual destruction.
|
|||
|
||||
Each interface has a single method. When the component implements that method, Angular calls it at the appropriate time.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Read more about lifecycle hooks in the [Lifecycle Hooks](guide/lifecycle-hooks) page.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -402,7 +402,7 @@ A *Promise* essentially promises to call back when the results are ready.
|
|||
You ask an asynchronous service to do some work and give it a callback function.
|
||||
The service does that work and eventually calls the function with the results or an error.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -411,7 +411,7 @@ This is a simplified explanation. Read more about ES2015 Promises in the
|
|||
[Exploring ES6](http://http://exploringjs.com/es6.html).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -447,7 +447,7 @@ Pass the callback function as an argument to the Promise's `then()` method:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -455,7 +455,7 @@ As described in [Arrow functions](https://developer.mozilla.org/en-US/docs/Web/J
|
|||
the ES2015 arrow function
|
||||
in the callback is more succinct than the equivalent function expression and gracefully handles `this`.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -464,13 +464,13 @@ The callback sets the component's `heroes` property to the array of heroes retur
|
|||
The app is still running, showing a list of heroes, and
|
||||
responding to a name selection with a detail view.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
At the end of this page, [Appendix: take it slow](tutorial/toh-pt4#slow) describes what the app might be like with a poor connection.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -27,14 +27,14 @@ When you’re done, users will be able to navigate the app like this:
|
|||
To satisfy these requirements, you'll add Angular’s router to the app.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
For more information about the router, read the [Routing and Navigation](guide/router) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -145,14 +145,14 @@ Here's the plan:
|
|||
* Tie the *Dashboard* into the navigation structure.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
*Routing* is another name for *navigation*. The router is the mechanism for navigating from view to view.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -254,7 +254,7 @@ at the top of the `<head>` section.
|
|||
|
||||
|
||||
|
||||
~~~ {.callout.is-important}
|
||||
<div class="callout is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -269,7 +269,7 @@ section of the [Routing and Navigation](guide/router) page.
|
|||
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -302,14 +302,14 @@ This route definition has the following parts:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Read more about defining routes with `Routes` in the [Routing & Navigation](guide/router) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -324,7 +324,7 @@ Import the `RouterModule` and add it to the `AppModule` imports array.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -333,7 +333,7 @@ The `forRoot()` method supplies the Router service providers and directives need
|
|||
performs the initial navigation based on the current browser URL.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -367,7 +367,7 @@ that tells the router where to navigate when the user clicks the link.
|
|||
Since the link is not dynamic, a routing instruction is defined with a one-time binding to the route path.
|
||||
Looking back at the route configuration, you can confirm that `'/heroes'` is the path of the route to the `HeroesComponent`.
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -376,14 +376,14 @@ in the [Appendix: Link Parameters Array](guide/router#link-parameters-array) sec
|
|||
[Routing & Navigation](guide/router) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
Refresh the browser. The browser displays the app title and heroes link, but not the heroes list.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -392,7 +392,7 @@ The route path to `HeroesComponent` is `/heroes`, not `/`.
|
|||
Soon you'll add a route that matches the path `/`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -466,7 +466,7 @@ to the array of route definitions:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -474,7 +474,7 @@ Read more about *redirects* in the [Redirecting routes](guide/router#!) section
|
|||
of the [Routing & Navigation](guide/router) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -489,14 +489,14 @@ Add a dashboard navigation link to the template, just above the *Heroes* link.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
The `<nav>` tags don't do anything yet, but they'll be useful later when you style the links.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -630,14 +630,14 @@ The colon (:) in the path indicates that `:id` is a placeholder for a specific h
|
|||
when navigating to the `HeroDetailComponent`.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Be sure to import the hero detail component before creating this route.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -731,7 +731,7 @@ The hero `id` is a number. Route parameters are always strings.
|
|||
So the route parameter value is converted to a number with the JavaScript (+) operator.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -744,7 +744,7 @@ the subscriptions. The subscriptions are cleaned up when the component is destro
|
|||
memory leaks, so you don't need to unsubscribe from the route `params` `Observable`.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -775,7 +775,7 @@ using the `Location` service you injected previously.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -784,7 +784,7 @@ In a real app, you can prevent this issue with the <em>CanDeactivate</em> guard.
|
|||
Read more on the [CanDeactivate](api/router/index/CanDeactivate-interface) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -978,14 +978,14 @@ Pipes are a good way to format strings, currency amounts, dates and other displa
|
|||
Angular ships with several pipes and you can write your own.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
Read more about pipes on the [Pipes](guide/pipes) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1034,7 +1034,7 @@ Set their properties to refer to the new files.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1042,7 +1042,7 @@ The `styleUrls` property is an array of style file names (with paths).
|
|||
You could list multiple style files from different locations if you needed them.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -1147,7 +1147,7 @@ Add an <code>app.component.css</code> file to the `app` folder with the followin
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -1158,7 +1158,7 @@ add a class to the HTML navigation element whose route matches the active route.
|
|||
All you have to do is define the style for it.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -121,7 +121,7 @@ Add the file `in-memory-data.service.ts` in `app` with the following content:
|
|||
This file replaces `mock-heroes.ts`, which is now safe to delete.
|
||||
|
||||
|
||||
~~~ {.alert.is-helpful}
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
||||
|
||||
|
@ -134,7 +134,7 @@ Read more about the in-memory web API in the
|
|||
section of the [HTTP Client](guide/server-communication#in-mem-web-api) page.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -203,14 +203,14 @@ That's as easy as importing them from the RxJS library like this:
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
You'll add more operators, and learn why you must do so, [later in this tutorial](tutorial/toh-pt6#rxjs-imports).
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -231,7 +231,7 @@ holds the array of heroes that the caller wants.
|
|||
So you grab that array and return it as the resolved Promise value.
|
||||
|
||||
|
||||
~~~ {.alert.is-important}
|
||||
<div class="alert is-important">
|
||||
|
||||
|
||||
|
||||
|
@ -240,7 +240,7 @@ This particular in-memory web API example returns an object with a `data` proper
|
|||
Your API might return something else. Adjust the code to match your web API.
|
||||
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -523,7 +523,7 @@ The `http.get()` call in `HeroSearchService` is similar to the one
|
|||
in the `HeroService`, although the URL now has a query string.
|
||||
|
||||
More importantly, you no longer call `toPromise()`.
|
||||
Instead you return the *Observable* from the the `htttp.get()`,
|
||||
Instead you return the *Observable* from the the `http.get()`,
|
||||
after chaining it to another RxJS operator, <code>map()</code>,
|
||||
to extract heroes from the response data.
|
||||
RxJS operator chaining makes response processing easy and readable.
|
||||
|
@ -616,7 +616,7 @@ before passing along the latest string. You'll never make requests more frequent
|
|||
It cancels and discards previous search observables, returning only the latest search service observable.
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -637,7 +637,7 @@ Note that until the service supports that feature, _canceling_ the `HeroSearchSe
|
|||
doesn't actually abort a pending HTTP request.
|
||||
For now, unwanted results are discarded.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
@ -915,7 +915,7 @@ Here are the files you added or changed in this page.
|
|||
|
||||
|
||||
|
||||
~~~ {.l-sub-section}
|
||||
<div class="l-sub-section">
|
||||
|
||||
|
||||
|
||||
|
@ -924,5 +924,5 @@ Here are the files you added or changed in this page.
|
|||
Return to the [learning path](guide/learning-angular#architecture), where
|
||||
you can read more about the concepts and practices found in this tutorial.
|
||||
|
||||
~~~
|
||||
</div>
|
||||
|
||||
|
|
Loading…
Reference in New Issue