Mithril js - 跨组件通信模式

Mithril js - cross component communication pattern

本文关键字：通信 模式 组件 js Mithril      更新时间：2023-09-26

我在这里对跨组件通信的实现 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]})

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

我的问题：

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

很好的例子。对我来说看起来很简洁。以"j"、"b"或"m"开始键入的一点提示将避免读取所有代码或假设示例已损坏;)

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

如果"项目"子视图

观察"用户"子视图会更有意义。这将允许子视图之间具有复杂且可重用的逻辑，并且具有仅限于启动的轻型仪表板。

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

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

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

相关文章：