教程-服务 一审完毕
This commit is contained in:
Zhicheng Wang
parent
55722de87a
commit
8beee32a65
|
|
@ -28,7 +28,7 @@ include ../_util-fns
|
|||
let’s verify we have the following structure after [Part 1](./toh-pt1.html).
|
||||
If not, we’ll need to go back to Part 1 and figure out what we missed.
|
||||
|
||||
在继续《英雄指南》的第二部分之前，我们先检查一下，完成[第一部分](./toh-pt1.html)之后，你是否已经有了如下目录结构。如果没有，你得先回到第一部分，看看错过了哪里。
|
||||
在继续《英雄指南》的第二部分之前，先来检查一下，完成[第一部分](./toh-pt1.html)之后，你是否已经有了如下目录结构。如果没有，你得先回到第一部分，看看错过了哪里。
|
||||
|
||||
.filetree
|
||||
.file angular2-tour-of-heroes
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ include ../_util-fns
|
|||
## 我们在哪儿
|
||||
Before we continue with our Tour of Heroes, let’s verify we have the following structure. If not, we’ll need to go back and follow the previous chapters.
|
||||
|
||||
在继续《英雄指南》之前，我们先检查一下，你是否已经有了如下目录结构。如果没有，你得先回上一章，看看错过了哪里。
|
||||
在继续《英雄指南》之前，先来检查一下，你是否已经有了如下目录结构。如果没有，你得先回上一章，看看错过了哪里。
|
||||
|
||||
.filetree
|
||||
.file angular2-tour-of-heroes
|
||||
|
|
|
|||
|
|
@ -5,21 +5,21 @@ include ../_util-fns
|
|||
# 服务
|
||||
The Tour of Heroes is evolving and we anticipate adding more components in the near future.
|
||||
|
||||
《英雄指南》继续前行。未来，我们准备添加更多的组件。
|
||||
《英雄指南》继续前行。接下来，我们准备添加更多的组件。
|
||||
|
||||
Multiple components will need access to hero data and we don't want to copy and
|
||||
paste the same code over and over.
|
||||
Instead, we'll create a single reusable data service and learn to
|
||||
inject it in the components that need it.
|
||||
|
||||
将会有更多的组件要访问英雄数据，但我们不想一遍又一遍的复制粘贴同样的代码。
|
||||
我们的替代方案是，创建一个单一的、可复用的数据服务，然后学习把它注入到那些想要用它的组件中去。
|
||||
将来会有更多的组件访问英雄数据，但我们不想一遍又一遍的复制粘贴同样的代码。
|
||||
我们的替代方案是，创建一个单一的、可复用的数据服务，然后学着把它注入到那些想用它的组件中去。
|
||||
|
||||
Refactoring data access to a separate service keeps the component lean and focused on supporting the view.
|
||||
It also makes it easier to unit test the component with a mock service.
|
||||
|
||||
重构数据访问代码，把它隔离到一个独立的服务中去，可以让组件保持精简，专注于为视图提供支持。
|
||||
如果想通过mock服务来对组件进行单元测试，在这种方式下也会变得更容易。
|
||||
我们将重构数据访问代码，把它隔离到一个独立的服务中去，让组件尽可能保持精简，专注于为视图提供支持。
|
||||
在这种方式下，借助mock服务来对组件进行单元测试也会更容易。
|
||||
|
||||
Because data services are invariably asynchronous,
|
||||
we'll finish the chapter with a promise-based version of the data service.
|
||||
|
|
@ -37,7 +37,7 @@ include ../_util-fns
|
|||
Before we continue with our Tour of Heroes, let’s verify we have the following structure.
|
||||
If not, we’ll need to go back and follow the previous chapters.
|
||||
|
||||
在继续《英雄指南》之前，我们先检查一下，你是否已经有了如下目录结构。如果没有，你得先回上一章，看看错过了哪里。
|
||||
在继续《英雄指南》之前，先来检查一下，你是否已经有了如下目录结构。如果没有，你得先回上一章，看看错过了哪里。
|
||||
|
||||
.filetree
|
||||
.file angular2-tour-of-heroes
|
||||
|
|
@ -62,7 +62,7 @@ include ../_util-fns
|
|||
Open a terminal/console window.
|
||||
Start the TypeScript compiler, watch for changes, and start our server by entering the command:
|
||||
|
||||
打开terminal/console窗口，启动TypeScript编译器，它会监视文件变更，并启动开发服务器。我们只要敲：
|
||||
打开terminal/console窗口，启动TypeScript编译器，它会监视文件变更，并启动开发服务器。只要敲：
|
||||
|
||||
code-example(format="." language="bash").
|
||||
npm start
|
||||
|
|
@ -80,10 +80,10 @@ code-example(format="." language="bash").
|
|||
Soon we'll add a dashboard with the top performing heroes and create a separate view for editing hero details.
|
||||
All three views need hero data.
|
||||
|
||||
客户描述了我们这个应用更广阔的图景。
|
||||
他们告诉我们，想要在不同的页面中用多种方式显示英雄。
|
||||
我们已经能从列表中选择一个英雄了。
|
||||
很快，我们将添加一个仪表盘来表彰绩效最好的英雄，并且创建一个独立的视图来编辑英雄的详情。
|
||||
客户向我们描绘了本应用更大的目标。
|
||||
他们说，想要在不同的页面中用多种方式显示英雄。
|
||||
现在我们已经能从列表中选择一个英雄了，但这还不够。
|
||||
很快，我们将添加一个仪表盘来表彰绩效最好的英雄，并且创建一个独立视图来编辑英雄的详情。
|
||||
所有这些视图都需要英雄的数据。
|
||||
|
||||
At the moment the `AppComponent` defines mock heroes for display.
|
||||
|
|
@ -91,13 +91,13 @@ code-example(format="." language="bash").
|
|||
First, defining heroes is not the component's job.
|
||||
Second, we can't easily share that list of heroes with other components and views.
|
||||
|
||||
目前，`AppComponent`显示的是自己定义的一个mock英雄数据。
|
||||
我们的改进点至少有两个：1. 定义英雄数据不应该是这个组件的任务。2. 要想把这个英雄列表数据共享给其它组件和视图可不容易。
|
||||
目前，`AppComponent`显示的是我们自定义的一个mock英雄数据。
|
||||
我们可改进的地方至少有两个：首先，定义英雄的数据不该是该组件的任务。其次，想把这份英雄列表的数据共享给其它组件和视图可不那么容易。
|
||||
|
||||
We can refactor this hero data acquisition business to a single service that provides heroes and
|
||||
share that service with all components that need heroes.
|
||||
|
||||
我们可以把提供英雄数据的业务移交给一个单一的服务，它将提供英雄数据，并且把这个服务在所有需要英雄数据的组件之间共享。
|
||||
我们可以把提供英雄数据的任务重构为一个单独的服务，它将提供英雄数据，并且把这个服务在所有需要英雄数据的组件之间共享。
|
||||
|
||||
### Create the HeroService
|
||||
### 创建HeroService
|
||||
|
|
@ -111,8 +111,8 @@ code-example(format="." language="bash").
|
|||
The `SpecialSuperHeroService` would be defined in the `special-super-hero.service.ts` file.
|
||||
|
||||
我们遵循的文件命名约定是：服务名称的小写形式（基本名），加上`.service`后缀。
|
||||
如果服务名称包含多个字母，我们把基本名部分拼成中线形式（dash-case，也被称作烤串形式kebab-case）。
|
||||
于是，`SpecialSuperHeroService`服务应该被定义在`special-super-hero.service.ts`文件中。
|
||||
如果服务名称包含多个单词，我们就把基本名部分写成中线形式（dash-case，也被称作烤串形式kebab-case）。
|
||||
比如，`SpecialSuperHeroService`服务应该被定义在`special-super-hero.service.ts`文件中。
|
||||
:marked
|
||||
We name the class `HeroService` and export it for others to import.
|
||||
|
||||
|
|
@ -125,49 +125,50 @@ code-example(format="." language="bash").
|
|||
### 可注入的服务
|
||||
Notice that we imported the Angular `Injectable` function and applied that function as an `@Injectable()` decorator.
|
||||
|
||||
注意，我们引入了Angular的`Injectable`函数，并且通过`@Injectable()`装饰器的形式使用这个函数。
|
||||
注意，我们引入了Angular的`Injectable`函数，并通过`@Injectable()`装饰器使用这个函数。
|
||||
.callout.is-helpful
|
||||
:marked
|
||||
**Don't forget the parentheses!** Neglecting them leads to an error that's difficult to diagnose.
|
||||
**不要忘了写圆括号！** 如果忘了写，就会导致一个非常难以诊断的错误。
|
||||
|
||||
**不要忘了写圆括号！**如果忘了写，就会导致一个很难诊断的错误。
|
||||
:marked
|
||||
TypeScript sees the `@Injectable()` decorator and emits metadata about our service,
|
||||
metadata that Angular may need to inject other dependencies into this service.
|
||||
|
||||
TypeScript看到`@Injectable()`装饰器时，就会记下关于这个服务的元数据。当Angular需要往这个服务中注入其它依赖时，就会用到这些元数据。
|
||||
当TypeScript看到`@Injectable()`装饰器时，就会记下本服务的元数据。如果Angular需要往这个服务中注入其它依赖，就会使用这些元数据。
|
||||
|
||||
The `HeroService` doesn't have any dependencies *at the moment*. Add the decorator anyway.
|
||||
It is a "best practice" to apply the `@Injectable()` decorator *from the start*
|
||||
both for consistency and for future-proofing.
|
||||
|
||||
此刻，`HeroService`还不能拥有任何依赖。添加上这个装饰器。无论是从提高统一性还是减少变更的目的出发，都应该从一开始就加上`@Injectable()`装饰器，这是最佳实践。
|
||||
此刻，`HeroService`还没有任何依赖，但我们还是得加上这个装饰器。作为一项最佳实践，无论是出于提高统一性还是减少变更的目的，都应该从一开始就加上`@Injectable()`装饰器。
|
||||
|
||||
:marked
|
||||
### Getting Heroes
|
||||
### 获取英雄
|
||||
Add a `getHeroes` method stub.
|
||||
|
||||
添加一个`getHeros`桩方法。
|
||||
添加一个名叫`getHeros`的桩方法。
|
||||
+makeExample('toh-4/ts/app/hero.service.1.ts', 'getHeroes-stub', 'hero.service.ts (getHeroes桩方法)')(format=".")
|
||||
:marked
|
||||
We're holding back on the implementation for a moment to make an important point.
|
||||
|
||||
在这个实现上暂停一会儿，我们来讲一个重点。
|
||||
在这个实现上暂停一下，我们先来讲一个重点。
|
||||
|
||||
The consumer of our service doesn't know how the service gets the data.
|
||||
Our `HeroService` could get `Hero` data from anywhere.
|
||||
It could get the data from a web service or local storage
|
||||
or from a mock data source.
|
||||
|
||||
我们这个服务的消费者并不知道它具体如何获取数据。
|
||||
我们的`HeroService`服务可以从任何地方获得英雄的数据。
|
||||
它可能从网络服务器获取，可能从浏览器的局部存储区获取，也可能是写在源码中的mock数据。
|
||||
消费者并不知道本服务会如何获取数据。
|
||||
我们的`HeroService`服务可以从任何地方获取英雄的数据。
|
||||
它可以从网络服务器获取，可以从浏览器的局部存储区获取，也可以是直接写在源码中的mock数据。
|
||||
|
||||
That's the beauty of removing data access from the component.
|
||||
We can change our minds about the implementation as often as we like,
|
||||
for whatever reason, without touching any of the components that need heroes.
|
||||
|
||||
我们从组件中移除了数据访问代码，干得漂亮。
|
||||
我们从组件中成功移除了数据访问代码，干得漂亮。
|
||||
这下子，我们可以随时改变数据访问的实现方式了。
|
||||
|
||||
### Mock Heroes
|
||||
|
|
@ -175,23 +176,23 @@ code-example(format="." language="bash").
|
|||
We already have mock `Hero` data sitting in the `AppComponent`. It doesn't belong there. It doesn't belong *here* either.
|
||||
We'll move the mock data to its own file.
|
||||
|
||||
我们已经在`AppComponent`组件中实现过mock的英雄数据了。它不该在那个文件，也不该在这个文件中！我们要把mock数据移到它自己的文件中去。
|
||||
我们曾在`AppComponent`组件中写过mock版的英雄数据。它不该在那里，但也不该在*这里*！我们得把mock数据移到它自己的文件中去。
|
||||
|
||||
Cut the `HEROES` array from `app.component.ts` and paste it to a new file in the `app` folder named `mock-heroes.ts`.
|
||||
We copy the `import {Hero} ...` statement as well because the heroes array uses the `Hero` class.
|
||||
|
||||
从`app.component.ts`文件中剪切`HEROS`数组，并且把它粘贴到`app`目录下一个名叫`mock-heroes.ts`的文件中。
|
||||
从`app.component.ts`文件中剪切`HEROS`数组，并把它粘贴到`app`目录下一个名叫`mock-heroes.ts`的文件中。
|
||||
我们还要把`import {Hero}...`语句拷贝过来，因为我们的英雄数组用到了`Hero`类。
|
||||
+makeExample('toh-4/ts/app/mock-heroes.ts', null, 'mock-heroes.ts (英雄数组)')
|
||||
:marked
|
||||
We export the `HEROES` constant so we can import it elsewhere — such as our `HeroService`.
|
||||
|
||||
我们导出`HEROES`常量，以便在其它地方导入它 —— 比如`HeroService`服务。
|
||||
我们导出了`HEROES`常量，以便在其它地方导入它 —— 比如`HeroService`服务。
|
||||
|
||||
Meanwhile, back in `app.component.ts` where we cut away the `HEROES` array,
|
||||
we leave behind an uninitialized `heroes` property:
|
||||
|
||||
与此同时，回到我们刚刚剪切出`HEROES`数组的`app.component.ts`文件，我们留下了一个尚未初始化的`heroes`属性：
|
||||
同时，回到刚剪切出`HEROES`数组的`app.component.ts`文件，我们留下了一个尚未初始化的`heroes`属性：
|
||||
+makeExample('toh-4/ts/app/app.component.1.ts', 'heroes-prop', 'app.component.ts (heroes属性)')(format=".")
|
||||
:marked
|
||||
### Return Mocked Heroes
|
||||
|
|
@ -199,8 +200,8 @@ code-example(format="." language="bash").
|
|||
Back in the `HeroService` we import the mock `HEROES` and return it from the `getHeroes` method.
|
||||
Our `HeroService` looks like this:
|
||||
|
||||
回到`HeroService`，我们导入`HEROES`常量，并且在`getHeroes`方法中返回它。
|
||||
我们的`HeroService`服务看起来像这样：
|
||||
回到`HeroService`，我们导入`HEROES`常量，并在`getHeroes`方法中返回它。
|
||||
我们的`HeroService`服务现在看起来是这样：
|
||||
+makeExample('toh-4/ts/app/hero.service.1.ts', null, 'hero.service.ts')(format=".")
|
||||
:marked
|
||||
### Use the Hero Service
|
||||
|
|
@ -211,42 +212,42 @@ code-example(format="." language="bash").
|
|||
|
||||
We begin, as usual, by importing the thing we want to use, the `HeroService`.
|
||||
|
||||
通常，我们会从导入要用到的东西开始，比如`HeroService`。
|
||||
通常，我们会从导入要用的东西开始，比如`HeroService`。
|
||||
+makeExample('toh-4/ts/app/app.component.ts', 'hero-service-import', 'app.component.ts (导入HeroService)')
|
||||
:marked
|
||||
Importing the service allows us to *reference* it in our code.
|
||||
How should the `AppComponent` acquire a runtime concrete `HeroService` instance?
|
||||
|
||||
导入服务让我们可以在代码中引用它。
|
||||
导入这个服务让我们可以在代码中引用它。
|
||||
`AppComponent`该如何在运行中获得一个具体的`HeroService`实例呢？
|
||||
|
||||
### Do we *new* the *HeroService*? No way!
|
||||
### 我们要自己 *new* 出这个 *HeroService* 吗？没门！
|
||||
We could create a new instance of the `HeroService` with "new" like this:
|
||||
|
||||
我们可以使用`new`关键字来创建`HeroService`的实例，就像这样：
|
||||
固然，我们可以使用`new`关键字来创建`HeroService`的实例，就像这样：
|
||||
+makeExample('toh-4/ts/app/app.component.1.ts', 'new-service')(format=".")
|
||||
:marked
|
||||
That's a bad idea for several reasons including
|
||||
|
||||
但这不是个好主意，理由很多，比如：
|
||||
但这不是个好主意，有很多理由，比如：
|
||||
|
||||
* Our component has to know how to create a `HeroService`.
|
||||
If we ever change the `HeroService` constructor,
|
||||
we'll have to find every place we create the service and fix it.
|
||||
Running around patching code is error prone and adds to the test burden.
|
||||
|
||||
* 我们的组件不得不了解如何取创建`HeroService`。
|
||||
如果有一天我们修改了`HeroService`的构造函数，我们不得不找出我们创建此服务的每一处代码，并且修改它。
|
||||
给代码打补丁的行为容易导致错误，而且增加了测试的负担。
|
||||
* 我们的组件将不得不懂得该如何创建`HeroService`。
|
||||
如果有一天我们修改了`HeroService`的构造函数，我们不得不找出创建过此服务的每一处代码，并修改它。
|
||||
而给代码打补丁的行为容易导致错误，并增加了测试的负担。
|
||||
|
||||
* We create a new service each time we use "new".
|
||||
What if the service should cache heroes and share that cache with others?
|
||||
We couldn't do that.
|
||||
|
||||
* 我们每次使用`new`都会创建一个新的服务。
|
||||
如果这个服务需要缓存英雄列表，并且把这个缓存共享给别人，怎么办？
|
||||
没办法，这做不到。
|
||||
* 我们每次使用`new`都会创建一个新的服务实例。
|
||||
如果这个服务需要缓存英雄列表，并把这个缓存共享给别人呢？怎么办？
|
||||
没办法，做不到。
|
||||
|
||||
* We're locking the `AppComponent` into a specific implementation of the `HeroService`.
|
||||
It will be hard to switch implementations for different scenarios.
|
||||
|
|
@ -254,24 +255,24 @@ code-example(format="." language="bash").
|
|||
Will we need different mocked versions under test?
|
||||
Not easy.
|
||||
|
||||
* 我们把`AppComponent`锁定到了`HeroService`的一个特定实现中。
|
||||
我们很难在别的场景中把它更换为别的实现。
|
||||
* 我们把`AppComponent`锁死在`HeroService`的一个特定实现中。
|
||||
我们很难在别的场景中把它换成别的实现。
|
||||
比如，能离线操作吗？能在测试时使用不同的模拟版本吗？这可不容易。
|
||||
|
||||
*What if ... what if ... Hey, we've got work to do!*
|
||||
* 如果……如果……嘿！我们有得忙了！
|
||||
* 如果……如果……嘿！这下我们可有得忙了！
|
||||
|
||||
We get it. Really we do.
|
||||
But it is so ridiculously easy to avoid these problems that there is no excuse for doing it wrong.
|
||||
|
||||
我们有办法了，真的！这个办法真是简单得不可思议，它能解决这些问题，让你再也没有借口犯错误了。
|
||||
有办法了，真的！这个办法真是简单得不可思议，它能解决这些问题，你就再也没有犯错误的接口了。
|
||||
|
||||
### Inject the *HeroService*
|
||||
### 注入 *HeroService*
|
||||
|
||||
Two lines replace the one line of *new*:
|
||||
|
||||
用两行代码代替用`new`时的一行：
|
||||
用这两行代码代替用`new`时的一行：
|
||||
1. we add a constructor.
|
||||
1. 添加一个构造函数
|
||||
1. we add to the component's `providers` metadata
|
||||
|
|
@ -285,13 +286,13 @@ code-example(format="." language="bash").
|
|||
The constructor itself does nothing. The parameter simultaneously
|
||||
defines a private `_heroService` property and identifies it as a `HeroService` injection site.
|
||||
|
||||
构造函数自己什么也不用做，它的参数同时定义了一个私有的`_heroService`属性，并且把它标记为注入`HeroService`的靶点。
|
||||
构造函数自己什么也不用做，它在参数中定义了一个私有的`_heroService`属性，并把它标记为注入`HeroService`的靶点。
|
||||
.l-sub-section
|
||||
:marked
|
||||
We prefix private variables with an underscore (_) to warn readers of our code
|
||||
that this variable is not part of the component's public API.
|
||||
|
||||
我们给私有变量添加下划线（_）前缀，用以警告阅读我们代码的人：这个变量不是组件的公开API的一部分。
|
||||
我们给私有变量添加下划线（_）前缀，用以警告这些代码的读者：这个变量不是组件的公开API的一部分。
|
||||
:marked
|
||||
Now Angular will know to supply an instance of the `HeroService` when it creates a new `AppComponent`.
|
||||
|
||||
|
|
@ -304,7 +305,7 @@ code-example(format="." language="bash").
|
|||
|
||||
Angular得想办法获得这个实例。这就是Angular *依赖注入器（Dependency Injector）* 扮演的角色。
|
||||
这个 **注入器** 有一个包括以前创建过的所有服务的 **容器** 。
|
||||
它既可以从容器中查找并返回一个已存在的`HeroService`实例，也可以创建一个新的实例，把它添加到容器中，然后把它返回给Angular。
|
||||
它既可以从容器中查找并返回一个已存在的`HeroService`实例，又可以创建一个新的实例，把它添加到容器中，然后把它返回给Angular。
|
||||
|
||||
.l-sub-section
|
||||
:marked
|
||||
|
|
@ -316,18 +317,18 @@ code-example(format="." language="bash").
|
|||
The *injector* does not know yet how to create a `HeroService`.
|
||||
If we ran our code now, Angular would fail with an error:
|
||||
|
||||
*注入器* 还不知道该如何创建`HeroService`。
|
||||
如果现在运行我们的代码，Angular会失败，并报错：
|
||||
*注入器*还不知道该如何创建`HeroService`。
|
||||
如果现在运行我们的代码，Angular就会失败，并报错：
|
||||
code-example(format="." language="html").
|
||||
EXCEPTION: No provider for HeroService! (AppComponent -> HeroService)
|
||||
|
||||
EXCEPTION: No provider for HeroService! (AppComponent -> HeroService) —— 异常：没有HeroService的供应商(provider)！（AppComponent -> HeroService）
|
||||
EXCEPTION: No provider for HeroService! (AppComponent -> HeroService) —— 异常：没有HeroService的提供者(provider)！（AppComponent -> HeroService）
|
||||
:marked
|
||||
We have to teach the *injector* how to make a `HeroService` by registering a `HeroService` **provider**.
|
||||
Do that by adding the following `providers` array property to the bottom of the component metadata
|
||||
in the `@Component` call.
|
||||
|
||||
我们还得注册一个`HeroService` **供应商** ，以便教 *注入器* 如何创建`HeroService`。
|
||||
我们还得注册一个`HeroService`**Provider**，来告诉*注入器*如何创建`HeroService`。
|
||||
要做到这一点，我们应该在`@Component`组件的元数据底部添加`providers`数组属性如下：
|
||||
+makeExample('toh-4/ts/app/app.component.1.ts', 'providers', 'app.component.ts (提供HeroService)')
|
||||
:marked
|
||||
|
|
@ -335,7 +336,7 @@ code-example(format="." language="html").
|
|||
The `AppComponent` can use that service to get heroes and so can every child component of its component tree.
|
||||
|
||||
`providers`数组告诉Angular，在创建一个新的`AppComponent`时，也要创建一个`HeroService`的新鲜实例。
|
||||
`AppComponent`可以通过这个服务来获取英雄列表，在它组件树中的每一个子组件也可以这样做。
|
||||
`AppComponent`可以用此服务来获取英雄列表，它组件树中的每一个子组件也可以这么做。
|
||||
<a id="child-component"></a>
|
||||
.l-sub-section
|
||||
:marked
|
||||
|
|
@ -350,7 +351,7 @@ code-example(format="." language="html").
|
|||
If the `HeroDetailComponent` needed its parent component's `HeroService`,
|
||||
it would ask Angular to inject the service into its constructor which would look just like the one for `AppComponent`:
|
||||
|
||||
如果`HeroDetailComponent`需要访问来自它父组件的`HeroService`服务，它可以要求Angular把这个服务注入到自己的构造函数中 —— 就像`AppComponent`中的做法一样。
|
||||
如果`HeroDetailComponent`需要访问来自它父组件的`HeroService`服务，它可以要求Angular把这个服务注入到自己的构造函数中 —— 就像在`AppComponent`中的做法一样。
|
||||
|
||||
+makeExample('toh-4/ts/app/app.component.1.ts', 'ctor', 'hero-detail.component.ts (构造函数)')
|
||||
:marked
|
||||
|
|
@ -361,17 +362,17 @@ code-example(format="." language="html").
|
|||
The `AppComponent` is the top level component of our application.
|
||||
There should be only one instance of that component and only one instance of the `HeroService` in our entire app.
|
||||
|
||||
`AppComponent`是我们应用的顶层组件。在我们的整个应用中，应该有唯一的一个顶层组件，应该由唯一的一个`HeroService`实例。
|
||||
`AppComponent`是我们应用的顶层组件。在我们的整个应用中，应该有唯一的一个顶层组件，应该有唯一的一个`HeroService`实例。
|
||||
:marked
|
||||
### *getHeroes* in the *AppComponent*
|
||||
### *AppComponent* 中的 *getHeroes*
|
||||
We've got the service in a `_heroService` private variable. Let's use it.
|
||||
|
||||
我们已经获得了此服务，并且把它存入了私有变量`_heroService`中。我们这就开始使用它。
|
||||
我们已经获得了此服务，并把它存入了私有变量`_heroService`中。我们这就开始使用它。
|
||||
|
||||
We pause to think. We can call the service and get the data in one line.
|
||||
|
||||
停下来想一想。我们可以在同一行中调用服务并获得数据。
|
||||
停下来想一想。我们可以在同一行内调用此服务并获得数据。
|
||||
+makeExample('toh-4/ts/app/app.component.1.ts', 'get-heroes')(format=".")
|
||||
:marked
|
||||
We don't really need a dedicated method to wrap one line. We write it anyway:
|
||||
|
|
@ -392,29 +393,29 @@ code-example(format="." language="html").
|
|||
Years of experience and bitter tears have taught us to keep complex logic out of the constructor,
|
||||
especially anything that might call a server as a data access method is sure to do.
|
||||
|
||||
多年的经验和惨痛的教训教育我们，把复杂的逻辑扔到构造函数外面去，特别是那些需要从服务器获取数据的逻辑更是如此。
|
||||
多年的经验和惨痛的教训教育我们，应该把复杂的逻辑扔到构造函数外面去，特别是那些需要从服务器获取数据的逻辑更是如此。
|
||||
|
||||
The constructor is for simple initializations like wiring constructor parameters to properties.
|
||||
It's not for heavy lifting. We should be able to create a component in a test and not worry that it
|
||||
might do real work — like calling a server! — before we tell it to do so.
|
||||
|
||||
构造函数是为了初始化而设计的，比如把构造函数的参数赋值给属性。
|
||||
它的负担不是应该过于沉重。我们应该能在测试中创建一个测试，而不用担心它会完成实际的工作 —— 比如和服务器通讯，我们将来才会主动要求它做这些。
|
||||
构造函数是为了简单的初始化工作而设计的，比如把构造函数的参数赋值给属性。
|
||||
它的负担不应该过于沉重。我们应该能在测试中创建一个组件，而不用担心它会做实际的工作 —— 比如和服务器通讯，直到我们主动要求它做这些。
|
||||
|
||||
If not the constructor, something has to call `getHeroes`.
|
||||
|
||||
如果不在构造函数中，总要有地方调用`getHeroes`吧。
|
||||
如果不在构造函数中，总得有地方调用`getHeroes`吧。
|
||||
|
||||
Angular will call it if we implement the Angular **ngOnInit** *Lifecycle Hook*.
|
||||
Angular offers a number of interfaces for tapping into critical moments in the component lifecycle:
|
||||
at creation, after each change, and at its eventual destruction.
|
||||
|
||||
只要我们实现了Angular的 **ngOnInit** *生命周期钩子* ，Angular就会调用这个钩子。
|
||||
这也不难。只要我们实现了Angular的 **ngOnInit** *生命周期钩子* ，Angular就会主动调用这个钩子。
|
||||
Angular提供了一些接口，用来介入组件生命周期的几个关键时间点：刚创建时、每次变化时，以及最终被销毁时。
|
||||
|
||||
Each interface has a single method. When the component implements that method, Angular calls it at the appropriate time.
|
||||
|
||||
每个接口都是一个单独的方法。只要组件实现了这个方法，Angular就会在合适的时间调用它。
|
||||
每个接口都有唯一的一个方法。只要组件实现了这个方法，Angular就会在合适的时机调用它。
|
||||
.l-sub-section
|
||||
:marked
|
||||
Learn more about lifecycle hooks in the [Lifecycle Hooks](../guide/lifecycle-hooks.html) chapter.
|
||||
|
|
@ -429,7 +430,7 @@ code-example(format="." language="html").
|
|||
We write an `ngOnInit` method with our initialization logic inside and leave it to Angular to call it
|
||||
at the right time. In our case, we initialize by calling `getHeroes`.
|
||||
|
||||
我们写下带有初始化逻辑的`ngOnInit`方法，然后留给Angular，供其在正确的时刻调用。在这个例子中，我们通过调用`getHeroes`来完成初始化。
|
||||
我们写下带有初始化逻辑的`ngOnInit`方法，然后留给Angular，供其在正确的时机调用。在这个例子中，我们通过调用`getHeroes`来完成初始化。
|
||||
+makeExample('toh-4/ts/app/app.component.1.ts', 'ng-on-init', 'app.component.ts (OnInit协议)')(format=".")
|
||||
:marked
|
||||
Our application should be running as expected, showing a list of heroes and a hero detail view
|
||||
|
|
@ -439,7 +440,7 @@ code-example(format="." language="html").
|
|||
|
||||
We're getting closer. But something isn't quite right.
|
||||
|
||||
我们就快完成了，但还有点事不太对劲。
|
||||
我们就快完成了，但还有点事情不太对劲儿。
|
||||
|
||||
## Async Services and Promises
|
||||
## 异步服务与承诺（Promise）
|
||||
|
|
@ -451,11 +452,11 @@ code-example(format="." language="html").
|
|||
:marked
|
||||
Ask for heroes and they are there in the returned result.
|
||||
|
||||
请求英雄数据，并且直接在结果中返回它。
|
||||
请求英雄数据，并直接在结果中返回它。
|
||||
|
||||
Someday we're going to get heroes from a remote server. We don’t call http yet, but we aspire to in later chapters.
|
||||
|
||||
将来，我们会从远端服务器上获取英雄数据。我们还没调用http，但是我们希望在将来的章节中这么做。
|
||||
将来，我们会从远端服务器上获取英雄数据。我们还没调用http，但在未来的章节中我们会希望这么做。
|
||||
|
||||
When we do, we'll have to wait for the server to respond and we won't be able to block the UI while we wait,
|
||||
even if we want to (which we shouldn't) because the browser won't block.
|
||||
|
|
@ -468,10 +469,10 @@ code-example(format="." language="html").
|
|||
|
||||
We'll use *promises*.
|
||||
|
||||
我们将使用 *承诺* 。
|
||||
我们将使用 *承诺（Promise）* 。
|
||||
|
||||
### The Hero Service makes a promise
|
||||
### `HeroService`生成一个承诺
|
||||
### `HeroService`会生成一个承诺
|
||||
|
||||
A **promise** is ... well it's a promise to call us back later when the results are ready.
|
||||
We ask an asynchronous service to do some work and give it a callback function.
|
||||
|
|
@ -479,12 +480,12 @@ code-example(format="." language="html").
|
|||
|
||||
**承诺** 就是 …… 好吧，它就是一个承诺 —— 在有了结果时，它承诺会回调我们。
|
||||
我们请求一个异步服务去做点什么，然后给它一个回调函数。
|
||||
它会去做（无论用哪种方式），完成的时候，它调用我们的回调函数，并通过参数把工作成果或者错误信息传给我们。
|
||||
它会去做（无论用哪种方式），一旦完成，它就会调用我们的回调函数，并通过参数把工作成果或者错误信息传给我们。
|
||||
.l-sub-section
|
||||
:marked
|
||||
We are simplifying. Learn about ES2015 Promises [here](http://exploringjs.com/es6/ch_promises.html) and elsewhere on the web.
|
||||
|
||||
这里只是粗浅的说说，要了解更多，请参见[这里](http://exploringjs.com/es6/ch_promises.html)以及在Web上搜索其它学习资源。
|
||||
这里只是粗浅的说说，要了解更多，请参见[这里](http://exploringjs.com/es6/ch_promises.html)或在Web上搜索其它学习资源。
|
||||
:marked
|
||||
Update the `HeroService` with this promise-returning `getHeroes` method:
|
||||
|
||||
|
|
@ -494,27 +495,27 @@ code-example(format="." language="html").
|
|||
We're still mocking the data. We're simulating the behavior of an ultra-fast, zero-latency server,
|
||||
by returning an **immediately resolved promise** with our mock heroes as the result.
|
||||
|
||||
我们继续使用模拟数据。我们通过返回一个 *立即完成的承诺* 的方式，模拟了一个超快、零延迟的超级服务器。
|
||||
我们继续使用模拟数据。我们通过返回一个 *立即解决的承诺* 的方式，模拟了一个超快、零延迟的超级服务器。
|
||||
### Act on the Promise
|
||||
### 基于承诺的行动
|
||||
Returning to the `AppComponent` and its `getHeroes` method, we see that it still looks like this:
|
||||
|
||||
回到`AppComponent`和它的`getHeroes`方法，我们看到它看起来还是像这样的：
|
||||
回到`AppComponent`和它的`getHeroes`方法，我们看到它看起来还是这样的：
|
||||
+makeExample('toh-4/ts/app/app.component.1.ts', 'getHeroes', 'app.component.ts (getHeroes - 老的)')(format=".")
|
||||
:marked
|
||||
As a result of our change to `HeroService`, we're now setting `this.heroes` to a promise rather than an array of heroes.
|
||||
|
||||
作为我们修改`HeroService`的结果，我们正在把`this.heroes`替换为一个承诺，而不再是一个英雄数组。
|
||||
在修改了`HeroService`之后，我们还要把`this.heroes`替换为一个承诺，而不再是一个英雄数组。
|
||||
|
||||
We have to change our implementation to *act on the promise when it resolves*.
|
||||
When the promise resolves successfully, *then* we will have heroes to display.
|
||||
|
||||
我们得修改我们的实现，把它变成 *基于承诺* 的，并且在承诺完成时再行动。
|
||||
一旦承诺成功的完成了，我们就会显示英雄数据。
|
||||
我们得修改这个实现，把它变成*基于承诺*的，并在承诺的事情被解决时再行动。
|
||||
一旦承诺的事情被成功解决，我们就会显示英雄数据。
|
||||
|
||||
We pass our callback function as an argument to the promise's **then** method:
|
||||
|
||||
我们把回调函数作为参数传给承诺对象的 **then** 函数：
|
||||
我们把回调函数作为参数传给承诺对象的**then**函数：
|
||||
+makeExample('toh-4/ts/app/app.component.ts', 'get-heroes', 'app.component.ts (getHeroes - 修改版)')(format=".")
|
||||
.l-sub-section
|
||||
:marked
|
||||
|
|
@ -522,7 +523,7 @@ code-example(format="." language="html").
|
|||
in the callback is more succinct than the equivalent function expression and gracefully handles *this*.
|
||||
|
||||
回调中所用的[ES2015箭头函数](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions)
|
||||
能比等价的函数表达式更加简明、优雅的处理 *this* 指针。
|
||||
能比等价的函数表达式更加快速、优雅的处理*this*指针。
|
||||
:marked
|
||||
Our callback sets the component's `heroes` property to the array of heroes returned by the service. That's all there is to it!
|
||||
|
||||
|
|
@ -536,10 +537,10 @@ code-example(format="." language="html").
|
|||
:marked
|
||||
Checkout the "[Take it slow](#slow)" appendix to see what the app might be like with a poor connection.
|
||||
|
||||
查看附件中的“[慢一点儿](#slow)”一节，以了解在较差的网络连接中这个应用会是什么样的。
|
||||
查看附件中的“[慢一点儿](#slow)”一节，来了解在较差的网络连接中这个应用会是什么样的。
|
||||
:marked
|
||||
### Review the App Structure
|
||||
### 回顾应用结构
|
||||
### 回顾本应用的结构
|
||||
Let’s verify that we have the following structure after all of our good refactoring in this chapter:
|
||||
|
||||
再检查下，经历了本章的所有重构之后，我们应该有了下列文件结构：
|
||||
|
|
@ -589,9 +590,9 @@ code-example(format="." language="html").
|
|||
* We defined our `HeroService` as a provider for our `AppComponent`
|
||||
* 我们把`HeroService`定义为`AppComponent`的一个供应商（provider）
|
||||
* We created mock hero data and imported them into our service
|
||||
* 我们创建了一个模拟的英雄数据，并且把它导入我们的服务中
|
||||
* 我们创建了一个模拟的英雄数据，并把它导入我们的服务中
|
||||
* We designed our service to return a promise and our component to get our data from the promise
|
||||
* 我们把服务改造为返回承诺的，并且让组件从承诺获取数据
|
||||
* 我们把服务改造为返回承诺的，并让组件从承诺获取数据
|
||||
|
||||
[Run the live example for part 4](/resources/live-examples/toh-4/ts/plnkr.html)
|
||||
|
||||
|
|
@ -603,9 +604,9 @@ code-example(format="." language="html").
|
|||
We want to create a dashboard, add menu links that route between the views, and format data in a template.
|
||||
As our app evolves, we’ll learn how to design it to make it easier to grow and maintain.
|
||||
|
||||
通过使用共享组件和服务，我们的《英雄指南》具有了更高的可复用性。
|
||||
我们还要创建一个仪表盘，还要添加菜单链接，路由到各个视图，还要在模板中格式化数据。
|
||||
随着我们应用的进化，我们还会学到如何进行设计，让它更容易扩展和维护。
|
||||
通过使用共享组件和服务，我们的《英雄指南》更有复用性了。
|
||||
我们还要创建一个仪表盘，要添加菜单链接，要路由到各个视图，还要在模板中格式化数据。
|
||||
随着我们应用的进化，我们还会学到如何进行设计，让它更易于扩展和维护。
|
||||
|
||||
We learn about Angular Component Router and navigation among the views in the [next tutorial](toh-pt5.html) chapter.
|
||||
|
||||
|
|
@ -646,18 +647,18 @@ code-example(format="." language="html").
|
|||
We stated [earlier](#child-component) that if we injected the parent `AppComponent` `HeroService`
|
||||
into the `HeroDetailComponent`, *we must not add a providers array* to the `HeroDetailComponent` metadata.
|
||||
|
||||
我们在[前面](#child-component)说过，如果我们把父组件`AppComponent`中的`HeroService`服务注入到`HeroDetailComponent`，
|
||||
*我们就不应该添加一个providers数组* 到`HeroDetailComponent`的元数据中。
|
||||
我们在[前面](#child-component)说过，如果在父组件`AppComponent`中把`HeroService`服务注入到`HeroDetailComponent`，
|
||||
*我们就不应该在`HeroDetailComponent`的元数据中再添加一个providers数组*。
|
||||
|
||||
Why? Because that tells Angular to create a new instance of the `HeroService` at the `HeroDetailComponent` level.
|
||||
The `HeroDetailComponent` doesn't want its *own* service instance; it wants its *parent's* service instance.
|
||||
Adding the `providers` array creates a new service instance that shadows the parent instance.
|
||||
|
||||
为什么呢？因为那会告诉Angular在`HeroDetailComponent`这一层创建一个新的`HeroService`实例。
|
||||
显然，在这个例子中，`HeroDetailComponent`不会希望创建 *自己的* 服务实例，它想要的是就父组件的服务实例。
|
||||
给组件添加一个`providers`数组（即：注册provider），就会创建一个新的服务实例，它会遮蔽父组件中的同名实例。
|
||||
显然，在这个例子中，`HeroDetailComponent`不会希望创建*自己的*服务实例，它想要的就是来自父组件的服务实例。
|
||||
给组件添加一个`providers`数组（即：注册provider），就会创建一个新的服务实例，而它会遮蔽父组件中的同名实例。
|
||||
|
||||
Think carefully about where and when to register a provider.
|
||||
Understand the scope of that registration. Be careful not to create a new service instance at the wrong level.
|
||||
|
||||
要想清楚，在哪里、在什么时候注册供应商（provider）。要理解注册的范围。小心！不要在错误的级别创建新的服务实例。
|
||||
务必想清楚，在哪里、在什么时候注册Provider。要理解注册的有效范围。小心点！不要在错误的级别上创建新的服务实例。
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ figure.image-display
|
|||
Before we continue with our Tour of Heroes, let’s verify that we have the following structure after adding our hero service
|
||||
and hero detail component. If not, we’ll need to go back and follow the previous chapters.
|
||||
|
||||
在继续《英雄指南》之前，我们先检查一下，在添加了英雄服务和英雄详情组件之后，你是否已经有了如下目录结构。如果没有，你得先回上一章，再照做一次。
|
||||
在继续《英雄指南》之前，先来检查一下，在添加了英雄服务和英雄详情组件之后，你是否已经有了如下目录结构。如果没有，你得先回上一章，再照做一次。
|
||||
.filetree
|
||||
.file angular2-tour-of-heroes
|
||||
.children
|
||||
|
|
|
|||
Loading…
Reference in New Issue