linux依赖组件_实现相互依赖组件的四种角度方法

linux依赖组件

Component is the basic building block of Angular applications. A typical Angular application is consisted of many separated components. Normally, each component usually represents one particular feature. Yet, there are some complicated features that need to use multiple components to implement, for example, DropDownComponent and DropDownGroupComponent:

组件是Angular应用程序的基本构建块。 典型的Angular应用程序由许多分离的组件组成。 通常，每个组件通常代表一个特定功能。 但是，有些复杂的功能需要使用多个组件来实现，例如DropDownComponent和DropDownGroupComponent ：

<drop-down-group>
  <drop-down>...</drop-down>
  <drop-down>...</drop-down>
  <drop-down>...</drop-down>
</drop-down-group>

Data sharing is the most difficult part to solve when implementing this kind of interdependent components. Here I have summarized four common built-in approaches to tackle the communication problem.

实现此类相互依赖的组件时，数据共享是最难解决的部分。 在这里，我总结了四种常见的内置方法来解决通信问题。

1.组分注入 (1. Component Injection)

The simplest approach to establish a direct communication channel is through component injection from the children.

建立直接通信渠道的最简单方法是通过孩子注入组件。

@Component(...)
export class DropDownComponent {
  constructor(
    parent: DropDownGroupComponent
  ) {
    ...
  }
  ...
}

Component injection is a very useful feature powered by the Angular dependency injection engine which allows developers to inject the reference of any ancestor in the constructor through the engine. This approach is potentially the cleanest way to implement interdependent components with the least amount of code. Yet, the weakness is the strong coupling between two components, which leads to very bad code reusability. Hence, it is not suitable for complicated features. Besides, there is a limitation that the communication is totally bottom-up and child-driven, which makes it difficult to implement features that have parent-driven logic.

组件注入是由Angular依赖注入引擎提供支持的一项非常有用的功能，它允许开发人员通过引擎注入构造函数中任何祖先的引用。 这种方法可能是用最少的代码来实现相互依赖的组件的最干净的方法。 然而，弱点是两个组件之间的强耦合，这导致非常差的代码可重用性。 因此，它不适用于复杂的功能。 此外，通信是完全自下而上且由子级驱动的，这使实现具有父级驱动逻辑的功能变得困难。

For a more detailed example, please check out the following article:

有关更详细的示例，请查看以下文章：

2.服务 (2. Service)

The another approach that also utilizes the Angular dependency injection engine is service. It is basically an improved version of component injection. The concept is very similar. Yet, instead of injecting the parent component directly from the children, a service is created and provided as a middleman to handle the cross component logic.

还利用Angular依赖注入引擎的另一种方法是服务。 它基本上是组件注入的改进版本。 这个概念非常相似。 但是，不是直接从子级注入父组件，而是创建了一个服务并将其作为中间人提供来处理跨组件逻辑。

@Injectable()
export class DropDownService {
  ...
}@Component({
  ...
  providers: [ DropDownService ]
})
export class DropDownGroupComponent {
  constructor(
    dropDownService: DropDownService
  ) {
    ...
  }
  ...
}@Component(...)
export class DropDownComponent {
  constructor(
    dropDownService: DropDownService
  ) {
    ...
  }
  ...
}

Unlike component injection, the coupling is much looser. It is more flexible and reusable.

与组件注入不同，该耦合更为宽松。 它更加灵活和可重用。

It can be easily reused by techniques like service inheritance to implement child components that are shared by multiple parents.

可以通过诸如服务继承之类的技术轻松地重用它，以实现由多个父级共享的子级组件。

<google-map>
  <map-marker></map-marker>
  <map-marker></map-marker>
  <map-marker></map-marker>
</google-map><apple-map>
  <map-marker></map-marker>
  <map-marker></map-marker>
  <map-marker></map-marker>
</apple-map>

Besides, the service can be used to encapsulate the cross component logic, which highly improves the code readability. The greatest weakness is the large amount of code to maintain an extra service and also the data flow between the service and components, which also means extra maintenance overhead. It may be overkill to use this approach to implement relatively simple features. Furthermore, this approach is still bottom-up, which shares the same limitation of component injection.

此外，该服务可用于封装跨组件逻辑，从而大大提高了代码的可读性。 最大的弱点是用于维护额外服务的大量代码以及服务与组件之间的数据流，这也意味着额外的维护开销。 使用这种方法来实现相对简单的功能可能会过大。 此外，这种方法仍然是自下而上的，它具有相同的组分注入限制。

For a more detailed example, please check out the following article:

有关更详细的示例，请查看以下文章：

3.内容参考 (3. Content Reference)

For features that don’t fit with bottom-up approaches, here is a top-down alternative. Instead of using dependency injection, parents use query to retrieve the references of children. It is similar to the classic web components that use a lot of getElementByXxxx().

对于不适合自底向上方法的功能，这是自顶向下的替代方法。 父母不使用依赖项注入，而是使用查询来检索孩子的引用。 它类似于使用大量getElementByXxxx()的经典Web组件。

@Component(...)
export class DropDownGroupComponent {
  @ContentChildren(DropDownComponent) 
  markers: QueryList<DropDownComponent>;
  ...
}

The major advantage of top-down approach is that the children don’t need to keep any cross component logic. Yet, it is usually the least preferred approach most of the cases. For the previous approaches, they utilize the parent reference, which is static and never changed during the whole lifecycle. However, for the child references, they are are dynamic and changing. Handling content change is very troublesome in Angular. It is very likely to have high complexity code logic, which is bad for long term maintenance.

自上而下方法的主要优点是，子级不需要保留任何跨组件逻辑。 但是，在大多数情况下，它通常是最不受欢迎的方法。 对于先前的方法，它们利用父引用，该父引用是静态的，并且在整个生命周期中从未更改。 但是，对于子引用，它们是动态的并且正在变化。 在Angular中处理内容更改非常麻烦。 它很可能具有高复杂度的代码逻辑，这对长期维护不利。

For a more detailed example, please check out the following article:

有关更详细的示例，请查看以下文章：

4.模板插座 (4. Template Outlet)

The last approach I would like to introduce is template outlet, which is definitely one of the least known features of Angular. It is an Angular built-in directive that takes a template reference and render that template with a given context. It is very similar to an anonymous function, but for HTML instead of JavaScript. Here is an example:

我想介绍的最后一种方法是模板输出，这绝对是Angular鲜为人知的功能之一。 这是一个Angular内置指令，它接受模板引用并使用给定的上下文呈现该模板。 它与匿名函数非常相似，但是用于HTML而不是JavaScript。 这是一个例子：

<drop-down-group>
  <ng-template let-sharedData="sharedData">
    <drop-down [sharedData]="sharedData">...</drop-down>
    <drop-down [sharedData]="sharedData">...</drop-down>
    <drop-down [sharedData]="sharedData">...</drop-down>
  </ng-template>
</drop-down-group>

While in the DropDownGroupComponet:

在DropDownGroupComponet ：

@Component({
  ...
  template: `
    <ng-container *ngTemplateOutlet="templateRef; context: {
      sharedData: sharedData
    }"></ng-container>
  `
})
export class DropDownGroupComponent {
  @ContentChild(TemplateRef) templateRef: TemplateRef<any>;
  sharedData = '1234';  ...
}

It is the most generic approach to communicate between interdependent components, which is also the major advantage. There is basically no coupling between two components. It is useful when we want two components to work together in an one-off basis with the minimal extra code to add.

这是在相互依赖的组件之间进行通信的最通用方法，这也是主要优点。 两个组件之间基本上没有耦合。 当我们希望两个组件一次性添加最少的额外代码一起工作时，这很有用。

For a more detailed example, please check out the following article:

有关更详细的示例，请查看以下文章：

Thanks for reading! Hope you find this article helpful. Any comments would be highly appreciated. :D

谢谢阅读！ 希望本文对您有所帮助。 任何意见将不胜感激。 ：D

翻译自: https://medium.com/@liutingchun_95744/angular-four-approaches-to-implement-interdependent-components-769e9b39fd96

linux依赖组件