Angular 2 + / 4/5/6/7：智能，愚蠢和深度嵌套的组件通信

Question

注意：为简单起见，请将组件深度视为：

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

有关智能/大/父/子组件如何在MULTI-LEVEL（至少3级）链上下传递和传递数据的各种选项和条件。我们希望保持我们的聪明才智。 （宏）父组件作为唯一可以访问我们的数据服务（或原子/不可变存储）的组件，它将驱动信息与“哑”的交换。 （大）的儿童。我们看到的选项是：

1. 反模式（？）：通过@ Input / @输出绑定向下传递数据到组件链。这是一些人所说的“无关的属性”。或者＆＃39;自定义事件冒泡问题＆＃39;问题（例如：here和here。）问题。不行。
2. 反模式：通过@ViewChildren或@ContentChilden智能组件访问哑（大）孩子。这再次给孩子们带来了麻烦，但仍然没有为（大）孩子创建一个干净的机制来将数据UP传递给智能组件。
3. 如angular.io cookbook here中所述的共享邮件服务以及优秀的帖子here。
4. ？

现在，对于＆＃39; 3＆＃39;，哑（大）孩子必须注入消息服务。这让我想到了我的问题：

Q1：对于每个“哑巴”来说，这看起来很奇怪。 （盛大）孩子要注入留言服务。消息服务的最佳实践是为此系列提供专用服务，还是将数据服务放在“智能”服务上。祖父母被指控上述？

Q1A：另外，如果所有组件都注入了服务，那么这比在链上下添加@ Input / @输出绑定要好得多？ （我认为“哑巴组件需要某种方式来获取信息”这一论点）

Q2：如果＆＃39; smart＆＃39;盛大的父母正在与类似于redux的商店（我们的ngrx）进行沟通？再一次是与愚蠢的人交流。组件最好通过注入/专用消息服务发生，或者最好将商店注入每个“哑”中。组件......还是？注意，组件间通信是“动作”的组合。 （例如：表单验证，禁用按钮等）以及数据（即向/更新商店或服务添加数据）。

非常感谢！

Answer 1

（更新时间：02-07-2019：这篇文章过时了 - 添加了'store / ngrx'模式）

所以在进一步研究之后，当涉及到如何最好地向下和向上沟通嵌套组件链时，似乎真的只有两种选择 - 之间的Faustian讨价还价：

EITHER

• 向上传递@ Input / @输出绑定，并在整个嵌套组件链中传递（即处理'自定义事件冒泡'或'无关属性'的问题）

OR

• 使用消息传递/订阅服务在此系列组件之间进行通信（精彩描述here）并为链中的每个组件注入该服务。

OR：

• 反应商店模式（例如'ngrx'）是另一种选择。注意，IMO，智能和愚蠢组件的概念仍然适用。也就是说，哑组件永远不会直接访问商店。同样，智能组件是通过商店获取数据的主要方。

我个人支持使用智能和表现（'哑'）组件。添加“商店”也应该有选择地进行，因为它会显着增加流程的成本，从架构，一致的实施模式，开发和维护到新员工的入职。名义上，'哑'组件只需要@Inputs和@Outputs就是这样。它并不关心它在组件树中的深度或浅度 - 这就是应用程序问题。事实上，它并不关心应用程序首先使用它。同时，如果向其注入特定于应用程序的服务，则内部组件不会非常愚蠢或可移动。顺便说一句，对应的“智能”组件实际上是为其家族树中需要它的任何愚蠢组件提供中间服务（通过一流的@Injectable服务或类似于redux的商店）。智能组件也不关心其直接子项的@Inputs之外的组件，只要孙子以某种方式表示需要采取服务/存储操作（再次通过@ Input / @ Output链）。这样，智能组件也可以跨应用程序进行传输。

鉴于此，Faustian交易，IMO，倾向于利用@ Input / @ Output链及其带来的所有上述问题。也就是说，如果有人知道的话，我会密切注意这一点并欢迎干净和脱钩的替代品。