0

我在这里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]})

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

我的问题：

  1. 如果您必须在这两种实现之间进行选择，为什么要选择另一种呢？
  2. 在函数式编程模型中，像观察者模式这样的 OOP 概念是否令人不悦？
  3. 是否有更简洁但可扩展的方式在 FP / 使用不同的模式中实现这一点？
4

2 回答 2

1

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

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

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

于 2015-01-20T04:04:21.000 回答
0

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

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

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

于 2015-02-07T12:09:38.623 回答