角度智能（容器）/哑（表示）组件体系结构，条件逻辑和传播输入

Question

考虑两个愚蠢的组件A和B。组件C将显示A OR B之一，该组件C用于智能组件D。

  D (smart)
  |
  C (dumb)
 / \
A   B (both dumb)

A和B都有10个输入。我认为至少有几种方法可以解决此问题：

1. 即使我只使用了其中一半的输入，C仍接受了这20个输入，它们是组件A和B的输入的并集。

2. 使C成为智能组件，但这将意味着在现实世界中复杂的应用程序中，许多地方都会出现这种智能组件

3. 通过让C接受TemplateRef或类似内容来“投影” A和B组件，然后仅绑定D中的输入并让D决定显示哪个

4. 尝试将部分输入组合成更大的“输入对象”。似乎这会使数据绑定变得复杂，因为除非我和A和B在组件内部有不同的逻辑，否则它们只会被通知“输入对象”已更改，并且不知道更改的细节。

是否存在最佳实践或通用实践来处理这种情况？ A和B的输出出现一个类似的问题，并且在使用任何双向数据绑定时都会出现两种情况！

我曾尝试过搜索所有内容，甚至尝试为React而不是Angular寻找建议，但无济于事。

如果可以帮助我，我可以尝试生成一些与我正在处理的代码类似的示例代码，但这需要一些时间。

Answer 1

我会考虑将数据通信转移到共享服务，而不是尝试通过输入和输出传递所有数据。

如果组件“ C”不需要绑定到“ A”或“ B”的任何信息，则它根本不必处理它。

共享服务可能具有20个左右的数据项，以及“ A”和“ B”的“主题”或“行为主题”，以便将更改传达回“ D”。

我不确定您正在做的事情是否足够复杂以至于无法保证，但是如果您正在做很多这样的事情，那么Redux可以为您提供一个很好的模式。

最近，当简单的绑定过于简单时，我已经开始使用Redux并取得了巨大的成功。我发现ngrx / store有点繁琐，难以使用并且没有很好的文档记录，尽管它受到了很多压力，并且发现angular-redux（实际Redux库上的一个薄的Angular包装器）更易于使用，并且更好的文档。