fix(*): fix PUG syntax errors (#3401)
These errors are being missed by the Jade parser but the more stringent Pug parser treats them as errors.
This commit is contained in:
Pete Bacon Darwin
Jesús Rodríguez
parent
ea638482e5
commit
be53a50b6b
|
|
@ -75,7 +75,7 @@ a#q-declarable
|
|||
:marked
|
||||
## What is a _declarable_?
|
||||
|
||||
Declarables are the class types—components, directives, and pipes—that
|
||||
Declarables are the class types—components, directives, and pipes—that
|
||||
you can add to a module's `declarations` list.
|
||||
They're the _only_ classes that you can add to `declarations`.
|
||||
|
||||
|
|
@ -113,7 +113,7 @@ a#q-why-multiple-mentions
|
|||
* `AppComponent` could be declared in this module but not bootstrapped.
|
||||
* `AppComponent` could be bootstrapped in this module but declared in a different feature module.
|
||||
* `HeroComponent` could be imported from another app module (so you can't declare it) and re-exported by this module.
|
||||
* `HeroComponent` could be exported for inclusion in an external component's template
|
||||
* `HeroComponent` could be exported for inclusion in an external component's template
|
||||
as well as dynamically loaded in a pop-up dialog.
|
||||
|
||||
.l-hr
|
||||
|
|
@ -205,7 +205,7 @@ a#q-what-to-export
|
|||
If you don't export a class, it stays _private_, visible only to other component
|
||||
declared in this module.
|
||||
|
||||
You _can_ export any declarable class—components, directives, and pipes—whether
|
||||
You _can_ export any declarable class—components, directives, and pipes—whether
|
||||
it's declared in this module or in an imported module.
|
||||
|
||||
You _can_ re-export entire imported modules, which effectively re-exports all of their exported classes.
|
||||
|
|
@ -378,7 +378,7 @@ a#q-component-scoped-providers
|
|||
If another module elsewhere in the application also customizes `HttpBackend`
|
||||
or merely imports the `HttpModule`, it could override this module's `HttpBackend` provider,
|
||||
losing the special header. The server will reject http requests from this module.
|
||||
|
||||
|
||||
To avoid this problem, import the `HttpModule` only in the `AppModule`, the application _root module_.
|
||||
|
||||
If you must guard against this kind of "provider corruption", *don't rely on a launch-time module's `providers`.*
|
||||
|
|
@ -416,7 +416,7 @@ a#q-root-component-or-module
|
|||
## Should I add application-wide providers to the root _AppModule_ or the root _AppComponent_?
|
||||
|
||||
Register application-wide providers in the root `AppModule`, not in the `AppComponent`.
|
||||
|
||||
|
||||
Lazy-loaded modules and their components can inject `AppModule` services;
|
||||
they can't inject `AppComponent` services.
|
||||
|
||||
|
|
@ -734,7 +734,7 @@ table
|
|||
th(style="vertical-align: top") Feature Module
|
||||
th(style="vertical-align: top") Guidelines
|
||||
tr
|
||||
td(style="vertical-align: top")<a id="domain-feature-module"></a>Domain
|
||||
td(style="vertical-align: top") <a id="domain-feature-module"></a>Domain
|
||||
td
|
||||
:marked
|
||||
Domain feature modules deliver a user experience *dedicated to a particular application domain*
|
||||
|
|
@ -761,7 +761,7 @@ table
|
|||
For an example, see the [Make _Contact_ a feature module](../guide/ngmodule.html#contact-module-v1)
|
||||
section of the [NgModules](../guide/ngmodule.html) page, before routing is introduced.
|
||||
tr
|
||||
td(style="vertical-align: top")<a id="routed-feature-module"></a>Routed
|
||||
td(style="vertical-align: top") <a id="routed-feature-module"></a>Routed
|
||||
td
|
||||
:marked
|
||||
_Routed feature modules_ are _domain feature modules_
|
||||
|
|
@ -789,29 +789,29 @@ table
|
|||
Don't provide application-wide singleton services in a routed feature module
|
||||
or in a module that the routed module imports.
|
||||
tr
|
||||
td(style="vertical-align: top")<a id="routing-module"></a>Routing
|
||||
td(style="vertical-align: top") <a id="routing-module"></a>Routing
|
||||
td
|
||||
:marked
|
||||
A [routing module](../guide/router.html#routing-module) *provides routing configuration* for another module.
|
||||
|
||||
A routing module separates routing concerns from its companion module.
|
||||
|
||||
|
||||
A routing module typically does the following:
|
||||
* Defines routes.
|
||||
* Adds router configuration to the module's `imports`.
|
||||
* Re-exports `RouterModule`.
|
||||
* Adds guard and resolver service providers to the module's `providers`.
|
||||
|
||||
|
||||
The name of the routing module should parallel the name of its companion module, using the suffix "Routing".
|
||||
For example, `FooModule` in `foo.module.ts` has a routing module named `FooRoutingModule`
|
||||
in `foo-routing.module.ts`
|
||||
|
||||
If the companion module is the _root_ `AppModule`,
|
||||
the `AppRoutingModule` adds router configuration to its `imports` with `RouterModule.forRoot(routes)`.
|
||||
|
||||
If the companion module is the _root_ `AppModule`,
|
||||
the `AppRoutingModule` adds router configuration to its `imports` with `RouterModule.forRoot(routes)`.
|
||||
All other routing modules are children that import `RouterModule.forChild(routes)`.
|
||||
|
||||
A routing module re-exports the `RouterModule` as a convenience
|
||||
so that components of the companion module have access to
|
||||
A routing module re-exports the `RouterModule` as a convenience
|
||||
so that components of the companion module have access to
|
||||
router directives such as `RouterLink` and `RouterOutlet`.
|
||||
|
||||
A routing module *should not have its own `declarations`*.
|
||||
|
|
@ -827,7 +827,7 @@ table
|
|||
[Routing & Navigation](../guide/router.html) page.
|
||||
|
||||
tr
|
||||
td(style="vertical-align: top")<a id="service-feature-module"></a>Service
|
||||
td(style="vertical-align: top") <a id="service-feature-module"></a>Service
|
||||
td
|
||||
:marked
|
||||
Service modules *provide utility services* such as data access and messaging.
|
||||
|
|
@ -840,7 +840,7 @@ table
|
|||
Do *not* import service modules in other feature modules.
|
||||
If you deviate from this guideline, know what you're doing and why.
|
||||
tr
|
||||
td(style="vertical-align: top")<a id="widget-feature-module"></a>Widget
|
||||
td(style="vertical-align: top") <a id="widget-feature-module"></a>Widget
|
||||
td
|
||||
:marked
|
||||
A widget module makes *components, directives, and pipes* available to external modules.
|
||||
|
|
@ -969,7 +969,7 @@ a#q-template-reference
|
|||
.l-main-section
|
||||
:marked
|
||||
## How does Angular find components, directives, and pipes in a template?<br>What is a <i><b>template reference</b></i>?
|
||||
|
||||
|
||||
The [Angular compiler](#q-angular-compiler) looks inside component templates
|
||||
for other components, directives, and pipes. When it finds one, that's a "template reference".
|
||||
|
||||
|
|
|
|||
|
|
@ -127,7 +127,7 @@ a#attribute-directives
|
|||
.l-sub-section
|
||||
block bootstrap-defn-top
|
||||
:marked
|
||||
You launch an Angular application by "bootstrapping" it using the application root Angular module (`AppModule`). Bootstrapping identifies an application's top level "root" [component](#component), which is the first component that is loaded for the application.
|
||||
You launch an Angular application by "bootstrapping" it using the application root Angular module (`AppModule`). Bootstrapping identifies an application's top level "root" [component](#component), which is the first component that is loaded for the application.
|
||||
For more information, see the [Setup](!{docsLatest}/guide/setup.html) page.
|
||||
:marked
|
||||
You can bootstrap multiple apps in the same `index.html`, each app with its own top-level root.
|
||||
|
|
@ -181,9 +181,9 @@ a#component
|
|||
:marked
|
||||
Applications display data values to a user and respond to user
|
||||
actions (such as clicks, touches, and keystrokes).
|
||||
|
||||
In data binding, you declare the relationship between an HTML widget and data source
|
||||
and let the framework handle the details.
|
||||
|
||||
In data binding, you declare the relationship between an HTML widget and data source
|
||||
and let the framework handle the details.
|
||||
Data binding is an alternative to manually pushing application data values into HTML, attaching
|
||||
event listeners, pulling changed values from the screen, and
|
||||
updating application data values.
|
||||
|
|
@ -458,12 +458,12 @@ a#jit
|
|||
- ES2015 modules, as described in this section.
|
||||
|
||||
:marked
|
||||
A cohesive block of code dedicated to a single purpose.
|
||||
|
||||
A cohesive block of code dedicated to a single purpose.
|
||||
|
||||
Angular apps are modular.
|
||||
|
||||
In general, you assemble an application from many modules, both the ones you write and the ones you acquire from others.
|
||||
|
||||
|
||||
A module *exports* something of value in that code, typically one thing such as a class;
|
||||
a module that needs that class *imports* it.
|
||||
|
||||
|
|
@ -712,7 +712,7 @@ a#structural-directives
|
|||
The process of transforming code written in one form of JavaScript
|
||||
(such as TypeScript) into another form of JavaScript (such as [ES5](#es5)).
|
||||
|
||||
:marked
|
||||
:marked
|
||||
## TypeScript
|
||||
.l-sub-section
|
||||
:marked
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ block includes
|
|||
:marked
|
||||
## Why dependency injection?
|
||||
|
||||
To understand why dependency injection is so important, consider an example without it.
|
||||
To understand why dependency injection is so important, consider an example without it.
|
||||
Imagine writing the following code:
|
||||
|
||||
+makeExample('dependency-injection/ts/src/app/car/car-no-di.ts', 'car', 'src/app/car/car.ts (without DI)')
|
||||
|
|
@ -69,7 +69,7 @@ block includes
|
|||
That makes `Car` brittle.
|
||||
|
||||
What if you want to put a different brand of tires on your `Car`? Too bad.
|
||||
You're locked into whatever brand the `Tires` class creates. That makes the
|
||||
You're locked into whatever brand the `Tires` class creates. That makes the
|
||||
`Car` class inflexible.
|
||||
|
||||
Right now each new car gets its own `engine`. It can't share an `engine` with other cars.
|
||||
|
|
@ -102,7 +102,7 @@ block includes
|
|||
'src/app/car/car.ts (excerpt with DI), src/app/car/car.ts (excerpt without DI)')(format=".")
|
||||
|
||||
:marked
|
||||
See what happened? The definition of the dependencies are
|
||||
See what happened? The definition of the dependencies are
|
||||
now in the constructor.
|
||||
The `Car` class no longer creates an `engine` or `tires`.
|
||||
It just consumes them.
|
||||
|
|
@ -199,7 +199,7 @@ block ctor-syntax
|
|||
Angular ships with its own dependency injection framework. This framework can also be used
|
||||
as a standalone module by other applications and frameworks.
|
||||
|
||||
To see what it can do when building components in Angular,
|
||||
To see what it can do when building components in Angular,
|
||||
start with a simplified version of the `HeroesComponent`
|
||||
that from the [The Tour of Heroes](../tutorial/).
|
||||
|
||||
|
|
@ -247,14 +247,14 @@ block ctor-syntax
|
|||
:marked
|
||||
.l-sub-section
|
||||
:marked
|
||||
The `@Injectable()` #{_decorator} above the service class is
|
||||
The `@Injectable()` #{_decorator} above the service class is
|
||||
covered [shortly](#injectable).
|
||||
|
||||
- var _perhaps = _docsFor == 'dart' ? '' : 'perhaps';
|
||||
.l-sub-section
|
||||
:marked
|
||||
Of course, this isn't a real service.
|
||||
If the app were actually getting data from a remote server, the API would have to be
|
||||
If the app were actually getting data from a remote server, the API would have to be
|
||||
asynchronous, #{_perhaps} returning a !{_PromiseLinked}.
|
||||
You'd also have to rewrite the way components consume the service.
|
||||
This is important in general, but not in this example.
|
||||
|
|
@ -285,14 +285,14 @@ block register-provider-ngmodule
|
|||
a#register-providers-ngmodule
|
||||
:marked
|
||||
### Registering providers in an _NgModule_
|
||||
Here's the `AppModule` that registers two providers, `UserService` and an `APP_CONFIG` provider,
|
||||
Here's the `AppModule` that registers two providers, `UserService` and an `APP_CONFIG` provider,
|
||||
in its `providers` !{_array}.
|
||||
|
||||
- var app_module_ts = 'src/app/app.module.ts';
|
||||
+makeExcerpt(app_module_ts + ' (excerpt)', 'ngmodule', app_module_ts)
|
||||
:marked
|
||||
Because the `HeroService` is used _only_ within the `HeroesComponent`
|
||||
and its subcomponents, the top-level `HeroesComponent` is the ideal
|
||||
Because the `HeroService` is used _only_ within the `HeroesComponent`
|
||||
and its subcomponents, the top-level `HeroesComponent` is the ideal
|
||||
place to register it.
|
||||
|
||||
a#register-providers-component
|
||||
|
|
@ -311,18 +311,18 @@ block ngmodule-vs-component
|
|||
On the one hand, a provider in an `NgModule` is registered in the root injector. That means that every provider
|
||||
registered within an `NgModule` will be accessible in the _entire application_.
|
||||
|
||||
On the other hand, a provider registered in an application component is available only on
|
||||
On the other hand, a provider registered in an application component is available only on
|
||||
that component and all its children.
|
||||
|
||||
Here, the `APP_CONFIG` service needs to be available all across the application, so it's
|
||||
Here, the `APP_CONFIG` service needs to be available all across the application, so it's
|
||||
registered in the `AppModule` `@NgModule` `providers` !{_array}.
|
||||
But since the `HeroService` is only used within the *Heroes*
|
||||
feature area and nowhere else, it makes sense to register it in
|
||||
feature area and nowhere else, it makes sense to register it in
|
||||
the `HeroesComponent`.
|
||||
|
||||
.l-sub-section
|
||||
:marked
|
||||
Also see *"Should I add app-wide providers to the root `AppModule` or
|
||||
Also see *"Should I add app-wide providers to the root `AppModule` or
|
||||
the root `AppComponent`?"* in the [NgModule FAQ](../cookbook/ngmodule-faq.html#q-root-component-or-module).
|
||||
|
||||
a#prep-for-injection
|
||||
|
|
@ -330,7 +330,7 @@ a#prep-for-injection
|
|||
### Preparing the _HeroListComponent_ for injection
|
||||
|
||||
The `HeroListComponent` should get heroes from the injected `HeroService`.
|
||||
Per the dependency injection pattern, the component must ask for the service in its
|
||||
Per the dependency injection pattern, the component must ask for the service in its
|
||||
constructor, [as discussed earlier](#ctor-injection).
|
||||
It's a small change:
|
||||
|
||||
|
|
@ -361,28 +361,28 @@ a#prep-for-injection
|
|||
Angular injector to inject an instance of
|
||||
`HeroService` whenever it creates a new `HeroListComponent`.
|
||||
|
||||
#di-metadata
|
||||
a#di-metadata
|
||||
:marked
|
||||
### Implicit injector creation
|
||||
|
||||
You saw how to use an injector to create a new
|
||||
`Car` earlier in this guide.
|
||||
You saw how to use an injector to create a new
|
||||
`Car` earlier in this guide.
|
||||
You _could_ create such an injector
|
||||
explicitly:
|
||||
|
||||
+makeExample('dependency-injection/ts/src/app/car/car-injector.ts','injector-create-and-call')(format=".")
|
||||
|
||||
:marked
|
||||
You won't find code like that in the Tour of Heroes or any of the other
|
||||
You won't find code like that in the Tour of Heroes or any of the other
|
||||
documentation samples.
|
||||
You *could* write code that [explicitly creates an injector](#explicit-injector) if you *had* to,
|
||||
You *could* write code that [explicitly creates an injector](#explicit-injector) if you *had* to,
|
||||
but it's not always the best choice.
|
||||
Angular takes care of creating and calling injectors
|
||||
when it creates components for you—whether through HTML markup, as in `<hero-list></hero-list>`,
|
||||
or after navigating to a component with the [router](./router.html).
|
||||
If you let Angular do its job, you'll enjoy the benefits of automated dependency injection.
|
||||
|
||||
a:#singleton-services
|
||||
a#singleton-services
|
||||
:marked
|
||||
### Singleton services
|
||||
|
||||
|
|
@ -435,7 +435,7 @@ a#service-needs-service
|
|||
You call that property within the `getHeroes()` method when anyone asks for heroes.
|
||||
|
||||
- var injUrl = '../api/core/index/Injectable-decorator.html';
|
||||
a#injectable
|
||||
a#injectable
|
||||
:marked
|
||||
### Why _@Injectable()_?
|
||||
|
||||
|
|
@ -450,7 +450,7 @@ block injectable-not-always-needed-in-ts
|
|||
As it happens, you could have omitted `@Injectable()` from the first
|
||||
version of `HeroService` because it had no injected parameters.
|
||||
But you must have it now that the service has an injected dependency.
|
||||
You need it because Angular requires constructor parameter metadata
|
||||
You need it because Angular requires constructor parameter metadata
|
||||
in order to inject a `Logger`.
|
||||
|
||||
.callout.is-helpful
|
||||
|
|
@ -480,13 +480,13 @@ block injectable-not-always-needed-in-ts
|
|||
:marked
|
||||
At runtime, injectors can read class metadata in the transpiled JavaScript code
|
||||
and use the constructor parameter type information
|
||||
to determine what things to inject.
|
||||
to determine what things to inject.
|
||||
|
||||
Not every JavaScript class has metadata.
|
||||
The TypeScript compiler discards metadata by default.
|
||||
If the `emitDecoratorMetadata` compiler option is true
|
||||
If the `emitDecoratorMetadata` compiler option is true
|
||||
(as it should be in the `tsconfig.json`),
|
||||
the compiler adds the metadata to the generated JavaScript
|
||||
the compiler adds the metadata to the generated JavaScript
|
||||
for _every class with at least one decorator_.
|
||||
|
||||
While any decorator will trigger this effect, mark the service class with the
|
||||
|
|
@ -589,8 +589,8 @@ block provider-ctor-args
|
|||
The first is the [token](#token) that serves as the key for both locating a dependency value
|
||||
and registering the provider.
|
||||
|
||||
The second is a !{_secondParam},
|
||||
which you can think of as a *recipe* for creating the dependency value.
|
||||
The second is a !{_secondParam},
|
||||
which you can think of as a *recipe* for creating the dependency value.
|
||||
There are many ways to create dependency values just as there are many ways to write a recipe.
|
||||
|
||||
#class-provider
|
||||
|
|
@ -709,7 +709,7 @@ block dart-diff-const-metadata-ctor
|
|||
:marked
|
||||
Although the `HeroService` has no access to the `UserService`, the factory function does.
|
||||
|
||||
You inject both the `Logger` and the `UserService` into the factory provider
|
||||
You inject both the `Logger` and the `UserService` into the factory provider
|
||||
and let the injector pass them along to the factory function:
|
||||
|
||||
+makeExample('dependency-injection/ts/src/app/heroes/hero.service.provider.ts','provider', 'src/app/heroes/hero.service.provider.ts (excerpt)')(format='.')
|
||||
|
|
@ -772,12 +772,12 @@ a#non-class-dependencies
|
|||
:marked
|
||||
### Non-class dependencies
|
||||
p
|
||||
| What if the dependency value isn't a class? Sometimes the thing you want to inject is a
|
||||
| What if the dependency value isn't a class? Sometimes the thing you want to inject is a
|
||||
block non-class-dep-eg
|
||||
| span string, function, or object.
|
||||
p
|
||||
| Applications often define configuration objects with lots of small facts
|
||||
| (like the title of the application or the address of a web API endpoint)
|
||||
| Applications often define configuration objects with lots of small facts
|
||||
| (like the title of the application or the address of a web API endpoint)
|
||||
block config-obj-maps
|
||||
| but these configuration objects aren't always instances of a class.
|
||||
| They can be object literals such as this one:
|
||||
|
|
@ -851,7 +851,7 @@ block dart-map-alternative
|
|||
|
||||
The `HeroService` *requires* a `Logger`, but what if it could get by without
|
||||
a `logger`?
|
||||
You can tell Angular that the dependency is optional by annotating the
|
||||
You can tell Angular that the dependency is optional by annotating the
|
||||
constructor argument with `@Optional()`:
|
||||
|
||||
+ifDocsFor('ts')
|
||||
|
|
@ -874,7 +874,7 @@ block dart-map-alternative
|
|||
|
||||
Angular dependency injection is more capable than this guide has described.
|
||||
You can learn more about its advanced features, beginning with its support for
|
||||
nested injectors, in
|
||||
nested injectors, in
|
||||
[Hierarchical Dependency Injection](hierarchical-dependency-injection.html).
|
||||
|
||||
.l-main-section#explicit-injector
|
||||
|
|
@ -896,7 +896,7 @@ block dart-map-alternative
|
|||
They are retrieved by calling `injector.get()`.
|
||||
|
||||
The `get()` method throws an error if it can't resolve the requested service.
|
||||
You can call `get()` with a second parameter, which is the value to return if the service
|
||||
You can call `get()` with a second parameter, which is the value to return if the service
|
||||
is not found. Angular can't find the service if it's not registered with this or any ancestor injector.
|
||||
|
||||
.l-sub-section
|
||||
|
|
@ -922,8 +922,8 @@ block dart-map-alternative
|
|||
Having multiple classes in the same file is confusing and best avoided.
|
||||
Developers expect one class per file. Keep them happy.
|
||||
|
||||
If you combine the `HeroService` class with
|
||||
the `HeroesComponent` in the same file,
|
||||
If you combine the `HeroService` class with
|
||||
the `HeroesComponent` in the same file,
|
||||
**define the component last**.
|
||||
If you define the component before the service,
|
||||
you'll get a runtime null reference error.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ block includes
|
|||
Once data arrive, you could push their raw `toString` values directly to the view,
|
||||
but that rarely makes for a good user experience.
|
||||
For example, in most use cases, users prefer to see a date in a simple format like
|
||||
<samp>April 15, 1988</samp> rather than the raw string format
|
||||
<samp>April 15, 1988</samp> rather than the raw string format
|
||||
<samp>Fri Apr 15 1988 00:00:00 GMT-0700 (Pacific Daylight Time)</samp>.
|
||||
|
||||
Clearly, some values benefit from a bit of editing. You may notice that you
|
||||
|
|
@ -17,7 +17,7 @@ block includes
|
|||
In fact, you might like to apply them in your HTML templates as you do styles.
|
||||
|
||||
Introducing Angular pipes, a way to write display-value transformations that you can declare in your HTML.
|
||||
|
||||
|
||||
You can run the <live-example></live-example> in Plunker and download the code from there.
|
||||
|
||||
.l-main-section
|
||||
|
|
@ -112,14 +112,14 @@ figure.image-display
|
|||
## Chaining pipes
|
||||
|
||||
You can chain pipes together in potentially useful combinations.
|
||||
In the following example, to display the birthday in uppercase,
|
||||
the birthday is chained to the `DatePipe` and on to the `UpperCasePipe`.
|
||||
In the following example, to display the birthday in uppercase,
|
||||
the birthday is chained to the `DatePipe` and on to the `UpperCasePipe`.
|
||||
The birthday displays as **<samp>APR 15, 1988</samp>**.
|
||||
|
||||
+makeExample('pipes/ts/src/app/app.component.html', 'chained-birthday')(format=".")
|
||||
|
||||
:marked
|
||||
This example—which displays **<samp>FRIDAY, APRIL 15, 1988</samp>**—chains
|
||||
This example—which displays **<samp>FRIDAY, APRIL 15, 1988</samp>**—chains
|
||||
the same pipes as above, but passes in a parameter to `date` as well.
|
||||
|
||||
+makeExample('pipes/ts/src/app/app.component.html', 'chained-parameter-birthday')(format=".")
|
||||
|
|
@ -178,7 +178,7 @@ figure.image-display
|
|||
Angular built-in pipes are pre-registered.
|
||||
|
||||
:marked
|
||||
To probe the behavior in the <live-example></live-example>,
|
||||
To probe the behavior in the <live-example></live-example>,
|
||||
change the value and optional exponent in the template.
|
||||
|
||||
## Power Boost Calculator
|
||||
|
|
@ -304,7 +304,7 @@ figure.image-display
|
|||
Or you might not use a pipe at all.
|
||||
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.
|
||||
|
||||
|
||||
:marked
|
||||
### Impure pipes
|
||||
|
||||
|
|
@ -355,7 +355,7 @@ h3#async-pipe The impure #[i AsyncPipe]
|
|||
The pipe maintains a subscription to the input `#{_Observable}` and
|
||||
keeps delivering values from that `#{_Observable}` as they arrive.
|
||||
|
||||
This next example binds an `#{_Observable}` of message strings
|
||||
This next example binds an `#{_Observable}` of message strings
|
||||
(`message#{_dollar}`) to a view with the `async` pipe.
|
||||
|
||||
+makeExample('pipes/ts/src/app/hero-async-message.component.ts', null, 'src/app/hero-async-message.component.ts')
|
||||
|
|
@ -382,7 +382,7 @@ h3#async-pipe The impure #[i AsyncPipe]
|
|||
Now demonstrate it in a harness component whose template defines two bindings to this pipe,
|
||||
both requesting the heroes from the `heroes.json` file.
|
||||
|
||||
+makeExample('src/app/hero-list.component.ts')
|
||||
+makeExample('src/app/hero-list.component.ts')
|
||||
:marked
|
||||
The component renders as the following:
|
||||
|
||||
|
|
@ -419,8 +419,8 @@ a#pure-pipe-pure-fn
|
|||
The built-in `DatePipe` is a pure pipe with a pure function implementation.
|
||||
So are the `ExponentialStrengthPipe` and `FlyingHeroesPipe`.
|
||||
A few steps back, you reviewed the `FlyingHeroesImpurePipe`—an impure pipe with a pure function.
|
||||
|
||||
But always implement a *pure pipe* with a *pure function*.
|
||||
|
||||
But always implement a *pure pipe* with a *pure function*.
|
||||
Otherwise, you'll see many console errors regarding expressions that changed after they were checked.
|
||||
|
||||
.l-main-section
|
||||
|
|
@ -458,7 +458,7 @@ a(id="no-filter-pipe")
|
|||
|
||||
The minification hazard is also compelling, if less obvious. Imagine a sorting pipe applied to a list of heroes.
|
||||
The list might be sorted by hero `name` and `planet` of origin properties in the following way:
|
||||
code-example(language="html")
|
||||
code-example(language="html").
|
||||
<!-- NOT REAL CODE! -->
|
||||
<div *ngFor="let hero of heroes | orderBy:'name,planet'"></div>
|
||||
:marked
|
||||
|
|
@ -467,7 +467,7 @@ code-example(language="html")
|
|||
Unfortunately, aggressive minification manipulates the `Hero` property names so that `Hero.name` and `Hero.planet`
|
||||
become something like `Hero.a` and `Hero.b`. Clearly `hero['name']` doesn't work.
|
||||
|
||||
While some may not care to minify this aggressively,
|
||||
While some may not care to minify this aggressively,
|
||||
the Angular product shouldn't prevent anyone from minifying aggressively.
|
||||
Therefore, the Angular team decided that everything Angular provides will minify safely.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ block includes
|
|||
Most of them can be safely ignored.
|
||||
|
||||
Application files _inside the_ **`src/`** and **`e2e/`** folders matter most to developers.
|
||||
|
||||
|
||||
Files _outside_ those folders condition the development environment.
|
||||
They rarely change and you may never view or modify them.
|
||||
If you do, this page can help you understand their purpose.
|
||||
|
|
@ -22,20 +22,20 @@ table(width="100%")
|
|||
td <code>src/app/</code>
|
||||
td
|
||||
:marked
|
||||
Angular application files go here.
|
||||
|
||||
Angular application files go here.
|
||||
|
||||
Ships with the "Hello Angular" sample's
|
||||
`AppComponent`, `AppModule`, a component unit test (`app.component.spec.ts`), and
|
||||
the bootstrap file, `main.ts`.
|
||||
|
||||
Try the <live-example name="setup">sample application</live-example>
|
||||
|
||||
Try the <live-example name="setup">sample application</live-example>
|
||||
and the <live-example name="setup" plnkr="quickstart-specs">unit test</live-example>
|
||||
as _live examples_.
|
||||
tr
|
||||
td <code>e2e/</code>
|
||||
td
|
||||
:marked
|
||||
_End-to-end_ (e2e) tests of the application,
|
||||
_End-to-end_ (e2e) tests of the application,
|
||||
written in Jasmine and run by the
|
||||
<a href="http://www.protractortest.org/" target="_blank" title="Protractor: end-to-end testing for Angular">protractor</a>
|
||||
e2e test runner.
|
||||
|
|
@ -55,7 +55,7 @@ table(width="100%")
|
|||
.travis.yml
|
||||
td
|
||||
:marked
|
||||
Tooling configuration files and folders.
|
||||
Tooling configuration files and folders.
|
||||
Ignore them until you have a compelling reason to do otherwise.
|
||||
tr
|
||||
td <code>CHANGELOG.md</code>
|
||||
|
|
@ -72,7 +72,7 @@ table(width="100%")
|
|||
td <code>index.html</code>
|
||||
td
|
||||
:marked
|
||||
The application host page.
|
||||
The application host page.
|
||||
It loads a few essential scripts in a prescribed order.
|
||||
Then it boots the application, placing the root `AppComponent`
|
||||
in the custom `<my-app>` body tag.
|
||||
|
|
@ -96,7 +96,7 @@ table(width="100%")
|
|||
:marked
|
||||
A list of files that you can delete if you want to purge your setup of the
|
||||
original QuickStart Seed testing and git maintainence artifacts.
|
||||
See instructions in the optional
|
||||
See instructions in the optional
|
||||
[_Deleting non-essential files_](setup.html#non-essential "Setup: Deleting non-essential files") section.
|
||||
*Do this only in the beginning to avoid accidentally deleting your own tests and git setup!*
|
||||
tr
|
||||
|
|
@ -109,16 +109,16 @@ table(width="100%")
|
|||
td
|
||||
:marked
|
||||
Identifies `npm `package dependencies for the project.
|
||||
|
||||
|
||||
Contains command scripts for running the application,
|
||||
running tests, and more. Enter `npm run` for a listing.
|
||||
<a href="https://github.com/angular/quickstart/blob/master/README.md#npm-scripts"
|
||||
<a href="https://github.com/angular/quickstart/blob/master/README.md#npm-scripts"
|
||||
target="_blank" title="npm scripts for Angular documentation samples">Read more</a> about them.
|
||||
tr
|
||||
td <code>protractor.config.js</code>
|
||||
td
|
||||
:marked
|
||||
Configuration for the
|
||||
Configuration for the
|
||||
<a href="http://www.protractortest.org/" target="_blank" title="Protractor: end-to-end testing for Angular">protractor</a>
|
||||
_end-to-end_ (e2e) test runner.
|
||||
tr
|
||||
|
|
@ -147,21 +147,21 @@ table(width="100%")
|
|||
td <code>systemjs<br>.config.extras.js</code>
|
||||
td
|
||||
:marked
|
||||
Optional extra SystemJS configuration.
|
||||
Optional extra SystemJS configuration.
|
||||
A way to add SystemJS mappings, such as for appliation _barrels_,
|
||||
without changing the original `system.config.js`.
|
||||
tr
|
||||
tr
|
||||
td <code>tsconfig.json</code>
|
||||
td
|
||||
:marked
|
||||
Tells the TypeScript compiler how to transpile TypeScript source files
|
||||
into JavaScript files that run in all modern browsers.
|
||||
tr
|
||||
tr
|
||||
td <code>tslint.json</code>
|
||||
td
|
||||
:marked
|
||||
The `npm` installed TypeScript linter inspects your TypeScript code
|
||||
and complains when you violate one of its rules.
|
||||
|
||||
This file defines linting rules favored by the
|
||||
|
||||
This file defines linting rules favored by the
|
||||
[Angular style guide](style-guide.html) and by the authors of the documentation.
|
||||
|
|
|
|||
|
|
@ -384,7 +384,7 @@ a#testbed
|
|||
and (b) `BannerComponent` doesn't interact with any other components.
|
||||
|
||||
|
||||
Call `configureTestingModule` within a `beforeEach` so that
|
||||
Call `configureTestingModule` within a `beforeEach` so that
|
||||
`TestBed` can reset itself to a base state before each test runs.
|
||||
|
||||
The base state includes a default testing module configuration consisting of the
|
||||
|
|
@ -702,8 +702,8 @@ a#testbed-get
|
|||
:marked
|
||||
The [`inject`](#inject) utility function is another way to get one or more services from the test root injector.
|
||||
|
||||
For a use case in which `inject` and `TestBed.get` do not work,
|
||||
see the section [_Override a component's providers_](#component-override), which
|
||||
For a use case in which `inject` and `TestBed.get` do not work,
|
||||
see the section [_Override a component's providers_](#component-override), which
|
||||
explains why you must get the service from the component's injector instead.
|
||||
|
||||
a#service-from-injector
|
||||
|
|
@ -896,10 +896,10 @@ a#jasmine-done
|
|||
Although there is no direct access to the `getQuote` promise inside `TwainComponent`,
|
||||
the spy has direct access, which makes it possible to wait for `getQuote` to finish.
|
||||
|
||||
Writing test functions with `done`, while more cumbersome than `async`
|
||||
and `fakeAsync`, is a viable and occasionally necessary technique.
|
||||
For example, you can't call `async` or `fakeAsync` when testing
|
||||
code that involves the `intervalTimer`, as is common when
|
||||
Writing test functions with `done`, while more cumbersome than `async`
|
||||
and `fakeAsync`, is a viable and occasionally necessary technique.
|
||||
For example, you can't call `async` or `fakeAsync` when testing
|
||||
code that involves the `intervalTimer`, as is common when
|
||||
testing async `Observable` methods.
|
||||
|
||||
a(href="#top").to-top Back to top
|
||||
|
|
@ -970,7 +970,7 @@ a#dashboard-standalone
|
|||
|
||||
:marked
|
||||
It verifies that the hero name is propagated to template with a binding.
|
||||
Because the template passes the hero name through the Angular `UpperCasePipe`,
|
||||
Because the template passes the hero name through the Angular `UpperCasePipe`,
|
||||
the test must match the element value with the uppercased name:
|
||||
+makeExample('testing/ts/src/app/dashboard/dashboard-hero.component.html')(format='.')
|
||||
:marked
|
||||
|
|
@ -1011,7 +1011,7 @@ a#trigger-event-handler
|
|||
care about the event object.
|
||||
|
||||
Other handlers are less forgiving. For example, the `RouterLink`
|
||||
directive expects an object with a `button` property
|
||||
directive expects an object with a `button` property
|
||||
that identifies which mouse button was pressed.
|
||||
This directive throws an error if the event object doesn't do this correctly.
|
||||
|
||||
|
|
@ -1032,7 +1032,7 @@ a#click-helper
|
|||
header click() is not an Angular testing utility
|
||||
:marked
|
||||
The `click()` helper function is **not** one of the Angular testing utilities.
|
||||
It's a function defined in _this guide's sample code_.
|
||||
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.
|
||||
:marked
|
||||
|
|
@ -1318,7 +1318,7 @@ a#import-module
|
|||
+makeExample('testing/ts/src/app/hero/hero-detail.component.spec.ts', 'setup-forms-module', 'src/app/hero/hero-detail.component.spec.ts (FormsModule setup)')(format='.')
|
||||
|
||||
:marked
|
||||
Because many app components need the `FormsModule` and the `TitleCasePipe`, the developer created
|
||||
Because many app components need the `FormsModule` and the `TitleCasePipe`, the developer created
|
||||
a `SharedModule` to combine these and other frequently requested parts.
|
||||
The test configuration can use the `SharedModule` too as seen in this alternative setup:
|
||||
|
||||
|
|
@ -1563,7 +1563,7 @@ a#why-stubbed-routerlink-tests
|
|||
|
||||
.alert.is-helpful
|
||||
:marked
|
||||
A future guide update will explain how to write such
|
||||
A future guide update will explain how to write such
|
||||
tests with the `RouterTestingModule`.
|
||||
|
||||
a(href="#top").to-top Back to top
|
||||
|
|
@ -1629,7 +1629,7 @@ a#attribute-directive
|
|||
|
||||
[Isolated unit tests](#isolated-unit-tests) might be helpful,
|
||||
but attribute directives like this one tend to manipulate the DOM.
|
||||
Isolated unit tests don't touch the DOM and, therefore,
|
||||
Isolated unit tests don't touch the DOM and, therefore,
|
||||
do not inspire confidence in the directive's efficacy.
|
||||
|
||||
A better solution is to create an artificial test component that demonstrates all ways to apply the directive.
|
||||
|
|
@ -1759,7 +1759,7 @@ a#isolated-pipe-tests
|
|||
### Pipes
|
||||
Pipes are easy to test without the Angular testing utilities.
|
||||
|
||||
A pipe class has one method, `transform`, that manipulates the input
|
||||
A pipe class has one method, `transform`, that manipulates the input
|
||||
value into a transformed output value.
|
||||
The `transform` implementation rarely interacts with the DOM.
|
||||
Most pipes have no dependence on Angular other than the `@Pipe`
|
||||
|
|
@ -1917,7 +1917,7 @@ a#testbed-class-summary
|
|||
### _TestBed_ class summary
|
||||
The `TestBed` class is one of the principal Angular testing utilities.
|
||||
Its API is quite large and can be overwhelming until you've explored it,
|
||||
a little at a time. Read the early part of this guide first
|
||||
a little at a time. Read the early part of this guide first
|
||||
to get the basics before trying to absorb the full API.
|
||||
|
||||
The module definition passed to `configureTestingModule`
|
||||
|
|
@ -2137,8 +2137,8 @@ table
|
|||
:marked
|
||||
Set this to `true` when you want the fixture to detect changes automatically.
|
||||
|
||||
When autodetect is `true`, the test fixture calls `detectChanges` immediately
|
||||
after creating the component. Then it listens for pertinent zone events
|
||||
When autodetect is `true`, the test fixture calls `detectChanges` immediately
|
||||
after creating the component. Then it listens for pertinent zone events
|
||||
and calls `detectChanges` accordingly.
|
||||
When your test code modifies component property values directly,
|
||||
you probably still have to call `fixture.detectChanges` to trigger data binding updates.
|
||||
|
|
@ -2216,7 +2216,7 @@ table
|
|||
td
|
||||
:marked
|
||||
The element's own component instance, if it has one.
|
||||
tr
|
||||
tr
|
||||
td(style="vertical-align: top") <code>context</code>
|
||||
td
|
||||
:marked
|
||||
|
|
|
|||
|
|
@ -1,15 +1,15 @@
|
|||
include ../_util-fns
|
||||
|
||||
:marked
|
||||
TypeScript is a primary language for Angular application development.
|
||||
TypeScript is a primary language for Angular application development.
|
||||
It is a superset of JavaScript with design-time support for type safety and tooling.
|
||||
|
||||
|
||||
Browsers can't execute TypeScript directly. Typescript must be "transpiled" into JavaScript using the *tsc* compiler,
|
||||
which requires some configuration.
|
||||
|
||||
|
||||
This page covers some aspects of TypeScript configuration and the TypeScript environment
|
||||
that are important to Angular developers, including details about the following files:
|
||||
|
||||
|
||||
* [tsconfig.json](#tsconfig)—TypeScript compiler configuration.
|
||||
* [typings](#typings)—TypesScript declaration files.
|
||||
|
||||
|
|
@ -28,7 +28,7 @@ a(id="tsconfig")
|
|||
+makeJson('quickstart/ts/src/tsconfig.1.json', null, 'tsconfig.json')(format=".")
|
||||
:marked
|
||||
This file contains options and flags that are essential for Angular applications.
|
||||
|
||||
|
||||
<a id="noImplicitAny"></a>
|
||||
### *noImplicitAny* and *suppressImplicitAnyIndexErrors*
|
||||
|
||||
|
|
@ -37,15 +37,15 @@ a(id="tsconfig")
|
|||
But your choice now can make a difference in larger projects, so it merits discussion.
|
||||
|
||||
When the `noImplicitAny` flag is `false` (the default), and if
|
||||
the compiler cannot infer the variable type based on how it's used,
|
||||
the compiler cannot infer the variable type based on how it's used,
|
||||
the compiler silently defaults the type to `any`. That's what is meant by *implicit `any`*.
|
||||
|
||||
|
||||
The documentation setup sets the `noImplicitAny` flag to `true`.
|
||||
When the `noImplicitAny` flag is `true` and the TypeScript compiler cannot infer
|
||||
the type, it still generates the JavaScript files, but it also **reports an error**.
|
||||
Many seasoned developers prefer this stricter setting because type checking catches more
|
||||
unintentional errors at compile time.
|
||||
|
||||
|
||||
You can set a variable's type to `any` even when the `noImplicitAny` flag is `true`.
|
||||
|
||||
When the `noImplicitAny` flag is `true`, you may get *implicit index errors* as well.
|
||||
|
|
@ -64,30 +64,30 @@ a(id="typings")
|
|||
Many JavaScript libraries, such as jQuery, the Jasmine testing library, and Angular,
|
||||
extend the JavaScript environment with features and syntax
|
||||
that the TypeScript compiler doesn't recognize natively.
|
||||
When the compiler doesn't recognize something, it throws an error.
|
||||
|
||||
When the compiler doesn't recognize something, it throws an error.
|
||||
|
||||
Use [TypeScript type definition files](https://www.typescriptlang.org/docs/handbook/writing-declaration-files.html)—`d.ts files`—to tell the compiler about the libraries you load.
|
||||
|
||||
|
||||
TypeScript-aware editors leverage these same definition files to display type information about library features.
|
||||
|
||||
|
||||
Many libraries include definition files in their npm packages where both the TypeScript compiler and editors
|
||||
can find them. Angular is one such library.
|
||||
can find them. Angular is one such library.
|
||||
The `node_modules/@angular/core/` folder of any Angular application contains several `d.ts` files that describe parts of Angular.
|
||||
|
||||
**You need do nothing to get *typings* files for library packages that include `d.ts` files.
|
||||
|
||||
**You need do nothing to get *typings* files for library packages that include `d.ts` files.
|
||||
Angular packages include them already.**
|
||||
|
||||
### lib.d.ts
|
||||
|
||||
TypeScript includes a special declaration file called `lib.d.ts`. This file contains the ambient declarations for various common JavaScript constructs present in JavaScript runtimes and the DOM.
|
||||
|
||||
Based on the `--target`, TypeScript adds _additional_ ambient declarations
|
||||
Based on the `--target`, TypeScript adds _additional_ ambient declarations
|
||||
like `Promise` if the target is `es6`.
|
||||
|
||||
Since the QuickStart is targeting `es5`, you can override the
|
||||
Since the QuickStart is targeting `es5`, you can override the
|
||||
list of declaration files to be included:
|
||||
|
||||
code-example(format=".")
|
||||
code-example(format=".").
|
||||
"lib": ["es2015", "dom"]
|
||||
|
||||
:marked
|
||||
|
|
@ -95,11 +95,11 @@ code-example(format=".")
|
|||
|
||||
### Installable typings files
|
||||
Many libraries—jQuery, Jasmine, and Lodash among them—do *not* include `d.ts` files in their npm packages.
|
||||
Fortunately, either their authors or community contributors have created separate `d.ts` files for these libraries and
|
||||
Fortunately, either their authors or community contributors have created separate `d.ts` files for these libraries and
|
||||
published them in well-known locations.
|
||||
|
||||
You can install these typings via `npm` using the
|
||||
[`@types/*` scoped package](http://www.typescriptlang.org/docs/handbook/declaration-files/consumption.html)
|
||||
You can install these typings via `npm` using the
|
||||
[`@types/*` scoped package](http://www.typescriptlang.org/docs/handbook/declaration-files/consumption.html)
|
||||
and Typescript, starting at 2.0, automatically recognizes them.
|
||||
|
||||
For instance, to install typings for `jasmine` you could do `npm install @types/jasmine --save-dev`.
|
||||
|
|
@ -108,8 +108,8 @@ code-example(format=".")
|
|||
QuickStart identifies two *typings*, or `d.ts`, files:
|
||||
|
||||
* [jasmine](http://jasmine.github.io/) typings for the Jasmine test framework.
|
||||
|
||||
* [node](https://www.npmjs.com/package/@types/node) for code that references objects in the *nodejs* environment;
|
||||
|
||||
* [node](https://www.npmjs.com/package/@types/node) for code that references objects in the *nodejs* environment;
|
||||
you can view an example in the [webpack](./webpack.html) page.
|
||||
|
||||
|
||||
QuickStart doesn't require these typings but many of the samples do.
|
||||
|
|
|
|||
Loading…
Reference in New Issue