Angular的后院：解决组件依赖关系 (Angular’s Backyard: The Resolving of Components Dependencies)

This article originally appeared on dormoshe.io

这篇文章 最初出现在dormoshe.io

Many of us use the Hierarchical Dependency Injection mechanism of Angular. We use it through a service or a component to resolve another service or provider. But, do we know what Angular does in order to resolve the dependencies? Probably not, because Angular takes care of what we need to use it as a black box.

我们中的许多人都使用Angular的分层依赖注入机制。我们通过服务或组件使用它来解析另一个服务或提供者。但是，我们知道Angular为了解决依赖关系做什么吗？可能不是，因为Angular会照顾我们需要将其用作黑匣子的情况。

In this article, we’ll open the black box and explore the code of the component dependencies resolution mechanism.

在本文中，我们将打开黑盒，并探索组件依赖关系解析机制的代码。

回到基础 (Back to the basics)

Dependency Injection (DI) is a powerful pattern for managing code dependencies. Angular’s DI system creates and delivers dependent services “just-in-time”. Angular has its own DI framework, and we can’t build an Angular application without it.

依赖注入 (DI)是一种用于管理代码依赖关系的强大模式。 Angular的DI系统可以 “及时” 创建并提供相关服务 。 Angular有自己的DI框架，没有它我们就无法构建Angular应用程序。

The Angular DI system is actually a Hierarchical system. This system supports nested injectors in parallel with the component tree. An injector creates dependencies using providers. We can reconfigure the injectors at any level of that component tree. Behind the scenes, each component sets up its own injector with zero, one, or more providers defined for that component itself.

Angular DI系统实际上是一个层次结构 系统。该系统支持与组件树并行的嵌套进样器。注入程序使用提供程序创建依赖关系。我们可以在该组件树的任何级别重新配置注入器。在幕后，每个组件都使用为该组件本身定义的零个，一个或多个提供程序来设置自己的注入器 。

解决顺序 (Resolution Order)

The hierarchical DI has an order to the resolution of the dependencies. When a component requests a dependency, if it exists in the @Component.providers array (the component injector), then this dependency will be supplied.

层次化DI对依存关系的解析具有顺序。当组件请求依赖项时，如果它存在于@Component.providers数组(组件注入器)中，则将提供此依赖项。

Elsewhere, Angular continues to the parent component injector and checks again and again. If Angular doesn’t find an ancestor, it will supply this dependency via the application main injector. This is the core concept of the hierarchical DI mechanism.

在其他地方，Angular继续使用父组件注入器并一次又一次地检查。如果Angular找不到祖先，它将通过应用程序主注入器提供此依赖关系。这是分层DI机制的核心概念。

让我们看一下代码 (Let’s see the code)

When Angular instantiates a component, it calls the resolveDep function. This function's signature contains the component view container, the element, the dependency definition and some more arguments. We will focus on the component view and the dependency object. The dependency object contains only one dependency of the component.

Angular实例化组件时，它将调用resolveDep函数。该函数的签名包含组件视图容器，元素，依赖项定义和更多参数。我们将专注于组件视图和依赖对象。依赖性对象仅包含组件的一种依赖性。

Here is the resolveDep function skeleton from the Angular GitHub repository:

这是Angular GitHub存储库中的resolveDep函数框架：

The function skeleton contains the main concepts of the resolution, without the edge cases. The full code can be found here. In the next parts, we will explore the function skeleton.

函数框架包含分辨率的主要概念，不包含边缘情况。完整的代码可以在这里找到。在接下来的部分中，我们将探索功能框架。

保沙 (Pausa)

The Exclamation mark is a new feature of Typescript 2.0. The ! post-fix expression operator may be used to assert that its operand is non-null and non-undefined in contexts where the type checker is unable to conclude that fact. Angular uses this feature frequently, so we should not be afraid.

感叹号是Typescript 2.0的新功能。 ! 在类型检查器无法得出结论的上下文中，可以使用后缀表达式运算符来断言其操作数是非null且未定义的。 Angular经常使用此功能，因此我们不用担心。

第1部分-准备 (Part 1 — Preparation)

The const startView = view; code saves the original view (the view container of the component) in a variable because the view variable will change soon.

const startView = view; 代码将原始视图(组件的视图容器)保存在一个变量中，因为view变量将很快更改。

The const tokenKey = depDef.tokenKey; code fetches the tokenKey or the dependency key, for example, HeroService_4. This key builds by the dependency name and a generated number to handle the dependency uniquely.

const tokenKey = depDef.tokenKey; 代码获取tokenKey或依赖项键，例如HeroService_4 。该键由依赖项名称和生成的数字构建，以唯一地处理依赖项。

第2部分-源组件和祖先搜索 (Part 2 —Source component and Ancestors search)

The while loop implements the stages of checking the source @Component.providers and the ancestor components. According to the dependency token key, the source component providers will be checked in lines 1–3:

while循环实现检查源@Component.providers和祖先组件的阶段。根据依赖性令牌密钥，将在第1–3行中检查源组件提供者：

If the provider exists on line 4, then the source component satisfies the dependency. So, if the dependency was instantiated in the past on line 6, the instance will return by the resolveDep function at line 10. If this is the first time that the component or its children ask for the dependency it will be created at line 7 and will return by the resolveDep function at line 10.

如果提供程序存在于第4行，则源组件满足依赖性。因此，如果依赖关系是在过去的第6行实例化的，则实例将在第10行由resolveDep函数返回。如果这是组件或其子级第一次请求依赖关系，它将在第7行创建，然后将由第10行的resolveDep函数返回。

If the dependency is not found in the view component injector, the elDef = viewParentEl(view) !; and view = view.parent !; will be called to advance the variable to the parent element. The while loop will continue running until the dependency is found in the ancestor injector. If the dependency is still not found after checking all ancestors, the while loop will end and the third part will come into action.

如果在view组件注入器中未找到依赖项，则elDef = viewParentEl(view) !; 和view = view.parent !; 将被调用以将变量前进到父元素。 while循环将继续运行，直到在祖先注入器中找到相关性为止。如果在检查所有祖先后仍未找到依赖项，则while循环将结束，并且第三部分将开始起作用。

第3部分-根注射器 (Part 3 — Root injector)

If come to this part, the dependency can’t be satisfied by any of the component ancestors injectors. Then the startView or the source component will be checked at line 1:

如果涉及到这一部分，则任何组件祖先注入器都无法满足这种依赖性。然后将在第1行检查startView或源组件：

If the source component or one of its ancestor components was loaded by the Router Outlet (the router component), the root injector is the Outlet Injector. This injector supplies some dependencies like the Router service. Otherwise, the root injector is the bootstrap component’s injector.

如果源组件或其祖先组件之一是由路由器出口(路由器组件)加载的，则根注入器为出口注入器 。该注入器提供了一些依赖性，例如路由器服务。否则，根注入器是自举组件的注入器。

If the dependency is found at line 3, then the value will be returned by the resolveDep function. In the other case, part 4 will come into action.

如果在第3行找到依赖项，那么resolveDep函数将返回该值。在其他情况下，第4部分将生效。

第4部分-应用模块注入器 (Part 4 — Application module injector)

When we come to this part, it means that the dependency can’t be satisfied by part 2 and part 3. This is the last chance to satisfy the dependency. This part’s code tries to get the dependency from the application module injector or the root module. This module contains the application-wide dependencies:return startView.root.ngModule.injector.get(depDef.token,notFoundValue);

当涉及到这一部分时，这意味着第2部分和第3部分不能满足依赖关系。这是满足依赖关系的最后机会。这部分的代码试图从应用程序模块注入器或根模块获取依赖关系。此模块包含应用程序范围的依赖项： return startView.root.ngModule.injector.get(depDef.token,notFoundValue);

This part finishes the resolveDep flow. If the dependency is not found, then Angular can’t satisfy this dependency and it should throw an exception.

本部分完成resolveDep流程。如果找不到依赖关系，则Angular无法满足此依赖关系，因此应引发异常。

结论 (Conclusion)

The Hierarchical DI is a core feature that Angular leans on a lot. Sometimes, the resolution process looks complicated and long. It’s very convenient to leave Angular to manage this flow and enjoy the ease of use. Now, after we hiked in the backyard of the component dependency resolution, we know what to expect when we use it.

分层DI是Angular所依赖的一项核心功能。有时，解析过程看起来很复杂且漫长。离开Angular管理此流程并享受易用性非常方便。现在，当我们在组件依赖关系解决方案的后院爬升之后，我们知道使用它时会发生什么。

You can follow me on dormoshe.io or Twitter to read more about Angular, JavaScript and web development.

您可以在dormoshe.io或Twitter上关注我，以了解有关Angular，JavaScript和Web开发的更多信息。