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

时间:2018-12-03 22:40:18

标签: angular architecture

考虑两个愚蠢的组件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寻找建议,但无济于事。

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

1 个答案:

答案 0 :(得分:0)

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

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

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

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

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