【问题标题】:Closure events bubble down关闭事件冒泡
【发布时间】:2013-01-09 22:10:03
【问题描述】:

我正在 Google 闭包中开发一个网络应用程序,其结构如下所示:

App
  + Control Pane
  |  + Search Box
  |  + Search Button
  + Result Pane
     + Results
     + Next Page Link

实际的组件结构要复杂得多。重要的一点是,整个组件树中有许多不同的组件可以启动某些操作。在此示例中,输入Search Box、按Search Button 或点击Next Page 都需要进行查询。

这很容易处理。组件树中任何地方的任何孩子都可以做

this.dispatchEvent(App.EventType.ACTION, ...)

App 将能够在事件向上传播时收听它。问题是另一个方向:当App 从它的查询中接收到数据时,它必须将它推送给所有的孩子。

App 尝试直接推送到Search boxResults 似乎非常脆弱,因为它们在组件树中的位置可能会发生变化。我想做的是触发 App.EventType.DATA_RECEIVED 事件并让所有孩子(和子孩子等)听到它。

我能找到的在谷歌关闭中做到这一点的唯一方法是创建一个App 的全局公共单例实例并用作所有App.EventType.DATA_RECEIVED 事件的源,或者探测App一直到所有的孩子和子孩子。

这两者都以自己的方式凌乱而脆弱。

有没有一种简单的闭包方法来调度向下冒泡的事件?

【问题讨论】:

  • 这听起来更像是我的设计决定。我假设您希望应用程序的其余部分可用的数据是模型的一部分,那么为什么不将各个组件连接起来以听取他们感兴趣的模型位并解析您所在位置的数据获取它并让模型调度更改事件。 ala 绑定。

标签: javascript events dom-events google-closure google-closure-library


【解决方案1】:

这不是一个非常令人满意的答案,但这是我决定的:

没有很好的方法可以在组件树中向下 传达这些内容。甚至闭包本身也会遇到这个问题,将 opt_domHelper 向下传递到每个子组件。

我的建议是为您的应用子类化 goog.ui.Component 并创建一个 myapp.Environment 类,其中包含 opt_domHelper 和其他环境变量,例如一个指定为应用程序事件通道的事件侦听器。

它本身并不是一个好的解决方案,但它是所有可能的弊端中最小的一个。如果你已经尽职尽责地到处传递opt_domHelper,那么问题就不会更糟了:管道变得更加可扩展,并且opt_domHelper 本身对实现者是隐藏的(他们现在传递environment)。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2011-10-20
    • 2011-08-23
    • 1970-01-01
    • 2021-08-14
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多