Angular 2 +/4/5/6/7:智能，哑巴和深层嵌套的组件通信 [英] Angular 2+/4/5/6/7: Smart, dumb and deeply nested component communication

问题描述

注意:为简单起见，请考虑以下组件的深度:

NOTE: for simplicity consider the component depths as:

- Smart (grand)parent level 0
  - dumb child level 1
   ....
    - dumb grandchild level 2
      ....)

关于智能/大/父/子组件如何通信以及在多级(至少3个级别)链上下传递数据的方式有多种选择和条件.我们希望将智能"(宏)父组件保留为唯一有权访问我们的数据服务(或原子/不可变存储)的组件，它将推动与哑"(宏)子代的信息交换.我们看到的选项是:

There are various options and conditions on how smart/grand/parent/child components communicate and pass data up and down a MULTI-LEVEL (at least 3 levels) chain. We'd like to keep our 'smart' (grand)parent component as the only component that has access to our data service (or atomic/immutable store) and it will drive exchange of information with 'dumb' (grand)children. The options we see are:

1. 反模式(?):通过@ Input/@ Output绑定在组件链中向上和向下传递数据.这就是所谓的外部属性"或自定义事件冒泡问题"问题(例如:此处和

1. Anti-pattern(?): Pass data down and up the component chain via @Input/@Output bindings. This is what some refer to as the 'extraneous properties' or 'custom event bubbling problem' problem (eg: here and here.) problem. No go.
2. Anti-pattern: Smart component access to dumb (grand)children via @ViewChildren or @ContentChilden. This again hardwires the children and still doesn't create a clean mechanism for the (grand)children to pass data UP to the smart component.
3. Shared message service as described in the angular.io cookbook here and an excellent post here.
4. ?

现在，如果为"3"，则必须为哑(大)子级注入消息服务.这使我想到了我的问题:

Now in case of '3', the dumb (grand)children must have the message service injected. Which brings me to my questions:

Q1:从直觉上来说，每个笨蛋"(大)孩子都注入了消息服务.消息服务成为该家庭的专用服务的最佳实践是它还是背负了上面提到的智能"祖父母负责的数据服务?

Q1: It seems intuitively odd for each of the 'dumb' (grand)children to have a message service injected. Is best practice for the message service to be a dedicated service for this family OR does it piggy back on the data service the 'smart' grandparent is charged with mentioned above?

Q1A:此外，如果所有组件都将注入服务，那么与在链上上下添加@ Input/@ Output绑定相比，这有什么好处? (我看到哑巴"组件需要某种方式来获取信息的说法)

Q1A: Additionally, how is this much better than adding @Input/@Output bindings up and down the chain if all the components will have a service injected? (I see the argument that the 'dumb' component needs SOME way to get info)

Q2:如果聪明"的祖父母正在与类似redux的商店(对我们来说是ngrx)进行通信，该怎么办?与哑巴"组件的通信再一次是最好通过注入/专用消息服务进行的，还是最好将商店注入到每个哑巴"组件中?或者?请注意，组件间通信是除数据(即向/向商店或服务添加数据/添加数据)之外的动作"(例如，表单验证，禁用按钮等)的组合.

Q2: What if the 'smart' grand parent were communicating with a redux-like store (ngrx for us)? Once again is the communication with the 'dumb' components best happen via an injected/dedicated messages service or is it best to inject the store into each 'dumb' component...or? Note, the inter-component communication is a combination of 'actions' (eg: form validation, disable button, etc) in addition to data (i.e. add data to/update store or service).

非常感谢！

推荐答案

(更新:02-07-2019:这篇文章过时了-增加了'store/ngrx'模式)

(UPDATE: 02-07-2019: This post was getting dated--added the 'store/ngrx' pattern)

因此，在进一步研究之后，当谈到如何在嵌套的组件链之间进行最佳沟通时，似乎实际上只有两个选择-浮士德式的讨价还价:

So after looking into this further, when it comes to how best to communicate down and up a nested component chain, there seems to be really only two options -- a Faustian bargain between:

以太

• 在整个嵌套组件链中上下传递@ Input/@ Output绑定(即处理自定义事件冒泡"或外部属性"的问题)

OR

• 使用消息传递/订阅服务在这组组件之间进行通信(详细说明此处)，并为链中的每个组件注入该服务.

• Use a messaging/subscription service to communicate between this family of components (great description here) and inject that service for each component in the chain.

OR:

• 反应式存储模式(例如'ngrx')是另一种选择.注意，IMO，智能组件和愚蠢组件的概念仍然适用.即，愚蠢的组件永远不会直接访问商店.同样，智能组件是通过商店获取数据的主要参与者.

我个人是利用智能和表示(哑")组件的支持者.添加存储"也应有选择地进行，因为这会显着增加流程的成本，从体系结构，一致的实施模式，开发和维护到新人员的入职.名义上，一个哑巴"组件只需要@Inputs和@Outputs就可以了.它不在乎组件树中的深度是多少，这就是应用程序的问题.实际上，它并不在乎什么应用程序首先使用它.同时，如果将特定于应用程序的服务注入其中，则深层组件就不会非常笨拙或难以运输.顺便说一句，对应的智能"组件实际上是(通过一流的@Injectable服务或类似redux的商店)向需要它的家谱中的任何哑组件提供中介服务.只要孙子孙以某种方式表示需要采取服务/存储操作(同样通过@ Input/@ Output链)，智能组件也不会关心其直接子孙的@Inputs之外的组件.这样，智能组件也可以跨应用程序线进行传输.

I'm personally a proponent of utilizing smart and presentational ('dumb') components. Adding a 'store' should also be done selectively as it significantly increases the costs of the process ranging from architecture, consistent implementation patterns, development, and maintenance to on-boarding of new personnel. Nominally, a 'dumb' component only needs @Inputs and @Outputs and that's it. It does not care how deep or shallow it is in a component tree--that's the applications problem. In fact it doesn't care what application uses it in the first place. Meanwhile, a deep down component isn't very dumb or transportable if an application specific service is injected into it. BTW, the counter-part 'smart' component is really providing intermediary services (via a first class @Injectable service or redux-like store) to whichever dumb component in its family tree that needs it. The smart component also doesn't care about components beyond its immediate child's @Inputs as long as the grandchildren somehow signal up a service/store action needs to be taken (again via the @Input/@Output chain). This way a smart component also becomes transportable across application lines.

鉴于此，浮士德式交易(IMO)倾向于利用@ Input/@ Output链以及它带来的所有上述问题.就是说，我一直在关注这一点，并欢迎任何人知道的清洁，脱钩的替代方案.

Given this, the Faustian bargain, IMO, leans towards utilizing an @Input/@Output chain with all the mentioned issues it brings with it. That said, I'm keeping an eye on this and welcome clean and decoupled alternatives if anyone knows of any.

这篇关于Angular 2 +/4/5/6/7:智能，哑巴和深层嵌套的组件通信的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！