Mithril js - 跨组件通信模式答案

【问题标题】：Mithril js - cross component communication patternMithril js - 跨组件通信模式
【发布时间】：2014-12-28 22:10:19
【问题描述】：

我在这里http://jsfiddle.net/c641oog2/ 的跨组件通信实现与这里描述的不同：http://lhorie.github.io/mithril/components.html#librarization。目标是创建一个易于集成和可扩展（可在其他组件中重用）的组件，即库化。

我的代码的主要部分：

var autocompleter = function(options) {
  ...
  autocompleter.vm = {
    list: m.prop(options.list || []),
    observers: m.prop(options.observers || []),
    ...
select: function(item) {
  for(observer in autocompleter.vm.observers()) {
    autocompleter.vm.observers()[observer](item); //notify all observers of selection
  }
}
  //initialization later on...
  this.userAC = new autocompleter({list: this.users(), observers: [this.selectedUser]})

主要区别在于组件之间的通信方式。在我的实现中，我决定使用观察者，在文档的实现中，他通过创建纯函数来实现，然后在仪表板的“视图”函数中使用这些函数，其中正确的参数被传递给自动完成的“视图”函数功能。

我的问题：

如果您必须在这两种实现之间进行选择，为什么要选择其中一种？
在函数式编程模型中，OOP 概念（例如观察者模式）是否令人不悦？
是否有更简洁但可扩展的方式在 FP 中/使用不同的模式来实现？

【问题讨论】：

标签： javascript functional-programming mithril.js

【解决方案1】：

很好的例子。在我看来很简洁。使用“j”、“b”或“m”开始输入的小提示将避免阅读所有代码或假设示例已损坏；）

对于像仪表板和子视图这样的集线器和辐条 getter/setter 安排，观察者模式只会增加额外的开销而没有任何解耦好处，因为无论如何仪表板都必须启动子视图。

如果“项目”子视图观察“用户”子视图会更有意义。这将允许子视图之间的复杂且可重用的逻辑与仅限于启动的轻型仪表板。

【讨论】：

【解决方案2】：

就个人而言，我更喜欢“纯”版本，而不是观察者模式。我认为从概念上讲它更简单。没有跨组件的交流，父母和孩子之间都是上下垂直的。

此外，您打破了（在我看来）UI 状态是数据的想法，因此理想情况下永远不会重复。

这意味着，如果您创建想要与其他组件交互的新组件，它们都需要保留所选状态的副本，而不是都观察单个 UI 状态模型。

【讨论】：