Polish hierarchical-dependency-injection.jade
This commit is contained in:
Yang Lin
parent
ad22e4e07d
commit
afdfe0b837
|
|
@ -5,7 +5,7 @@ block includes
|
|||
We learned the basics of Angular Dependency injection in the
|
||||
[Dependency Injection](./dependency-injection.html) chapter.
|
||||
|
||||
在[依赖注入](./dependency-injection.html)一章中，我们已经学过了Angular依赖注入的基础知识。
|
||||
在[依赖注入](./dependency-injection.html)一章中，我们已经学过了 Angular 依赖注入的基础知识。
|
||||
|
||||
Angular has a Hierarchical Dependency Injection system.
|
||||
There is actually a tree of injectors
|
||||
|
|
@ -13,8 +13,8 @@ block includes
|
|||
We can reconfigure the injectors at any level of that component tree with
|
||||
interesting and useful results.
|
||||
|
||||
Angular有一个多级依赖注入系统。
|
||||
实际上，应用程序中有一个与组件树平行的注入器树(译注：平行是指结构完全相同且一一对应)。
|
||||
Angular 有一个多级依赖注入系统。
|
||||
实际上，应用程序中有一个与组件树平行的注入器树（译注：平行是指结构完全相同且一一对应）。
|
||||
我们可以在组件树中的任何级别上重新配置注入器，达到一些有趣和有用的效果。
|
||||
|
||||
In this chapter we explore these points and write some code.
|
||||
|
|
@ -28,6 +28,7 @@ block includes
|
|||
.l-main-section
|
||||
:marked
|
||||
## The Injector Tree
|
||||
|
||||
## 注入器树
|
||||
|
||||
In the [Dependency Injection](./dependency-injection.html) chapter
|
||||
|
|
@ -38,12 +39,12 @@ block includes
|
|||
We oversimplified. In fact, there is no such thing as ***the*** injector!
|
||||
An application may have multiple injectors!
|
||||
|
||||
我们其实有点简化过度了。实际上，没有***那个(唯一的)***注入器这回事，因为一个应用中可能有很多注入器。
|
||||
我们其实有点简化过度了。实际上，没有***那个（唯一的）***注入器这回事，一个应用中可能有多个注入器。
|
||||
|
||||
An Angular application is a tree of components. Each component instance has its own injector!
|
||||
The tree of components parallels the tree of injectors.
|
||||
|
||||
一个Angular应用是一个组件树。每个组件实例都有自己的注入器！
|
||||
一个 Angular 应用是一个组件树。每个组件实例都有自己的注入器！
|
||||
组件的树与注入器的树平行。
|
||||
|
||||
|
||||
|
|
@ -53,13 +54,14 @@ block includes
|
|||
Every component doesn't need its own injector and it would be horribly inefficient to create
|
||||
masses of injectors for no good purpose.
|
||||
|
||||
Angular并没有像*字面上理解的*那样为每个组件都创建一个独立的注入器。
|
||||
不是每个组件都需要它自己的注入器，盲目创建大量没有明确用途的注入器是非常低效的。
|
||||
Angular 并没有像*字面上理解的*那样为每个组件都创建一个独立的注入器。
|
||||
不是每个组件都需要它自己的注入器，创建大量没有明确用途的注入器是非常低效的。
|
||||
|
||||
But it is true that every component ***has an injector*** (even if it shares that injector with another component)
|
||||
and there may be many different injector instances operating at different levels of the component tree.
|
||||
|
||||
但是，每个组件都**有一个注入器**是真实的(就算它与其它组件共享注入器，也是*有注入器*)，并且确实可能会有大量不同的注入器实例工作在组件树的不同级别。
|
||||
但是，每个组件都**有一个注入器**是真实的（就算它与其它组件共享注入器，也是*有注入器*），
|
||||
并且确实可能会有大量不同的注入器实例工作在组件树的不同级别。
|
||||
|
||||
It is useful to pretend that every component has its own injector.
|
||||
|
||||
|
|
@ -71,7 +73,7 @@ block includes
|
|||
The new twist is that the `HeroesListComponent` may hold and manage multiple instances of the `HeroesCardComponent`.
|
||||
|
||||
考虑《英雄指南》应用的一个简单变种，它由三个不同的组件构成：`HeroesApp`、`HeroesListComponent`和`HeroesCardComponent`。
|
||||
`HeroesApp`保存了`HeroesListComponent`的一个单例。
|
||||
`HeroesApp`保存了`HeroesListComponent`的一个实例。
|
||||
新的变化是，`HeroesListComponent`可以保存和管理`HeroesCardComponent`的多个实例。
|
||||
|
||||
The following diagram represents the state of the component tree when there are three instances of `HeroesCardComponent`
|
||||
|
|
@ -93,11 +95,11 @@ figure.image-display
|
|||
The requests keep bubbling up until we find an injector that can handle the request or run out of component ancestors.
|
||||
If we run out of ancestors, Angular throws an error.
|
||||
|
||||
当一个底层的组件申请获得一个依赖时，Angular先尝试用该组件自己的注入器来满足它。
|
||||
当一个底层的组件申请获得一个依赖时，Angular 先尝试用该组件自己的注入器来满足它。
|
||||
如果该组件的注入器没有找到对应的提供商，它就把这个申请转给它父组件的注入器来处理。
|
||||
如果那个注入器也无法满足这个申请，它就继续转给*它的*父组件的注入器。
|
||||
这个申请继续往上冒泡 —— 直到我们找到了一个能处理此申请的注入器或者超出了组件树中的祖先位置为止。
|
||||
如果超出了组件树中的祖先还未找到，Angular就会抛出一个错误。
|
||||
如果超出了组件树中的祖先还未找到，Angular 就会抛出一个错误。
|
||||
|
||||
.l-sub-section
|
||||
:marked
|
||||
|
|
@ -118,7 +120,8 @@ figure.image-display
|
|||
If we don't reconfigure, the tree of injectors appears to be flat. All requests bubble up to the root
|
||||
<span if-docs="ts">NgModule</span> injector that we configured with the `!{_bootstrapModule}` method.
|
||||
|
||||
如果我们完全没有进行过重新配置，注入器的树看起来将是“平面”的。所有的申请都会被冒泡到根<span if-docs="ts">NgModule</span>注入器进行处理，也就是我们在`!{_bootstrapModule}`方法中配置的那个。
|
||||
如果我们完全没有进行过重新配置，注入器的树看起来将是“平面”的。所有的申请都会被冒泡到根 <span if-docs="ts">NgModule</span>
|
||||
注入器进行处理，也就是我们在`!{_bootstrapModule}`方法中配置的那个。
|
||||
|
||||
The ability to configure one or more providers at different levels opens up interesting and useful possibilities.
|
||||
|
||||
|
|
@ -129,10 +132,10 @@ figure.image-display
|
|||
We create a child component (B) that defines its own providers for `Car` and `Engine`
|
||||
This child is the parent of another component (C) that defines its own provider for `Car`.
|
||||
|
||||
让我们回到“汽车(Car)”类的例子。
|
||||
假设“根注入器”(记为A)配置过`Car`、`Engine`和`Tires`的提供商。
|
||||
然后创建了一个子组件(B)，它为`Car`和`Engine`类定义了自己的提供商。
|
||||
这个子组件(B)又有另一个子组件(C)，(C)也为`Car`定义了自己的提供商。
|
||||
让我们回到“汽车 (Car) ”类的例子。
|
||||
假设“根注入器”（记为 A）配置过`Car`、`Engine`和`Tires`的提供商。
|
||||
然后创建了一个子组件(B)，它为`Car`和`Engine`定义了自己的提供商。
|
||||
这个子组件 (B) 又有另一个子组件 (C)，(C) 也为`Car`定义了自己的提供商。
|
||||
|
||||
Behind the scenes each component sets up its own injector with one or more providers defined for that component itself.
|
||||
|
||||
|
|
@ -142,8 +145,8 @@ figure.image-display
|
|||
its injector produces an instance of `Car` resolved by injector (C) with an `Engine` resolved by injector (B) and
|
||||
`Tires` resolved by the root injector (A).
|
||||
|
||||
当我们在最底层的组件(C)中试图解析出一个`Car`的实例时，注入器(C)解析出的`Car`类的实例，
|
||||
该`Car`的实例带有一个`Engine`类的实例(由注入器(B)解析出)和一个`Tires`类的实例(由跟注入器(A)解析出)。
|
||||
当我们在最底层的组件 (C) 中试图解析出一个`Car`的实例时，注入器 (C) 解析出的`Car`类的实例，
|
||||
该`Car`的实例带有一个`Engine`类的实例（由注入器 (B) 解析出）和一个`Tires`类的实例（由跟注入器 (A) 解析出）。
|
||||
|
||||
figure.image-display
|
||||
img(src="/resources/images/devguide/dependency-injection/injector-tree.png" alt="injector tree" width="600")
|
||||
|
|
@ -151,11 +154,12 @@ figure.image-display
|
|||
.l-main-section
|
||||
:marked
|
||||
## Component Injectors
|
||||
|
||||
## 组件注入器
|
||||
|
||||
In the previous section, we talked about injectors and how they are organized like a tree. Lookups follow the injector tree upwards until they find the requested thing to inject. But when do we actually want to provide providers on the root injector and when do we want to provide them on a child injector?
|
||||
|
||||
在前一节中，我们讨论了注入器以及它们是如何被组织成一棵树的。Angular会沿着注入器树往上逐级查找，直到发现了那个申请者要求注入的东西。
|
||||
在前一节中，我们讨论了注入器以及它们是如何被组织成一棵树的。Angular 会沿着注入器树往上逐级查找，直到发现了那个申请者要求注入的东西。
|
||||
但是，我们什么时候该在根注入器上提供提供商，什么时候又该在子注入器上提供它们呢？
|
||||
|
||||
Consider you are building a component to show a list of super heroes that displays each super hero in a card with its name and superpower. There should also be an edit button that opens up an editor to change the name and superpower of our hero.
|
||||
|
|
@ -184,7 +188,7 @@ figure.image-display
|
|||
Our `HeroesListComponent` defines a template that creates a list of `HeroCardComponent`s and `HeroEditorComponent`s, each bound to an instance of hero that is returned from the `HeroService`. Ok, that’s not entirely true. It actually binds to an `EditItem<Hero>` which is a simple generic datatype that can wrap any type and indicate if the item being wrapped is currently being edited or not.
|
||||
|
||||
我们的`HeroesListComponent`组件定义了一个模板，来创建`HeroCardComponent`和`HeroEditorComponent`的列表，
|
||||
它们的每个条目都绑定到一个由`HeroService`返回的Hero实例。
|
||||
它们的每个条目都绑定到一个由`HeroService`返回的 Hero 实例。
|
||||
好吧，这么说也不完全对。它实际上绑定到了一个`EditItem<Hero>`实例，这是一个简单的泛型数据类型，它可以包裹任何类型的实例，
|
||||
并额外添加一个`editing`属性，用来标记被包裹的实例是否正在编辑状态。
|
||||
|
||||
|
|
@ -224,12 +228,12 @@ figure.image-display
|
|||
:marked
|
||||
All this tiny service does is define an API to set a value of any type which can be altered, retrieved or set back to its initial value. That’s exactly what we need to implement the desired functionality.
|
||||
|
||||
这个微型服务唯一所做的是定义一个API来设置一个任意类型的值，它可以被修改、获取或者恢复成初始值。
|
||||
这个微型服务唯一所做的是定义一个 API 来设置一个任意类型的值，它可以被修改、获取或者恢复成初始值。
|
||||
这正是我们需要实现的功能。
|
||||
|
||||
Our `HeroEditComponent` uses this services under the hood for its `hero` property. It intercepts the `get` and `set` method to delegate the actual work to our `RestoreService` which in turn makes sure that we won’t work on the original item but on a copy instead.
|
||||
|
||||
我们的`HeroEditComponent`组件悄悄把这个服务用在它的`hero`属性上。它拦截了`get`和`set`方法，并把真正的工作委托给我们的`RestoreService`服务，这样可以确保我们并不是在操作原始条目，而是一个副本。
|
||||
我们的`HeroEditComponent`组件在幕后把这个服务用在它的`hero`属性上。它拦截了`get`和`set`方法，并把真正的工作委托给我们的`RestoreService`服务，这样可以确保我们并不是在操作原始条目，而是一个副本。
|
||||
|
||||
At this point we may be scratching our heads asking what this has to do with component injectors?
|
||||
Look closely at the metadata for our `HeroEditComponent`. Notice the `providers` property.
|
||||
|
|
@ -265,7 +269,7 @@ figure.image-display
|
|||
But we've learned that we can have multiple injectors operating at different levels of the application's component tree.
|
||||
Any of those injectors could have its own instance of the service.
|
||||
|
||||
这是否意味着在Angular 2中服务再也不是单例的了？是，也不是。
|
||||
这是否意味着在 Angular 2 中服务再也不是单例的了？是，也不是。
|
||||
对某一个具体的注入器来讲，仍然是每个服务类型只有一个实例。
|
||||
但我们已经知道，在应用程序组件树的各个不同级别上可以有多个注入器。
|
||||
任何一个注入器都可以有它自己的服务实例。
|
||||
|
|
@ -281,7 +285,7 @@ figure.image-display
|
|||
scoped to that component instance and its child components.
|
||||
|
||||
但很明显，这个场景下我们不希望这样。我们希望每个组件都有它自己的`RestoreService`实例。
|
||||
在组件级别上定义(或重定义)一个提供商，将会为该组件创建一个新的服务实例。
|
||||
在组件级别上定义（或重定义）一个提供商，将会为该组件创建一个新的服务实例。
|
||||
我们已经为`HeroEditComponent`制造了一种“私有”`RestoreService`单例，它的作用域被局限在了该组件的实例及其子组件中。
|
||||
|
||||
//- ## Advanced Dependency Injection in Angular
|
||||
|
|
|
|||
Loading…
Reference in New Issue