【问题标题】:Directive using a service fetching data: watch or broadcast?使用服务获取数据的指令:观看还是广播?
【发布时间】:2014-09-19 19:33:38
【问题描述】:

我创建了一个 JSFiddle 来说明我的情况:http://jsfiddle.net/hLv27/

我有一组指令应该相互独立,但会根据属性(主题)提供的数据进行更新。我可以通过多次使用相同的指令来举例说明:

<my-directive topics="main.topicList"></my-directive>
<my-directive topics="main.staticTopicList"></my-directive>
<my-directive topics="main.topicList" update-on="some.event"></my-directive>

每个指令根据主题从服务器获取其数据:

  • 在第一种情况下,我会使用$watch,观察topics 数组,并相应地获取新数据;

    $scope.$watch("topics", function (theTopics) {
        $scope.fetchData(theTopics);
    });
    
  • 在第二种情况下, 指令用固定数组初始化,我没有 之后需要更新它;

  • 在第三种情况下,我会添加到每个 指令一个update-on字符串,对应于一个广播 当topics 数组改变时触发。

    if ($scope.updateOn) {
        $scope.$on($scope.updateOn, function (ev, tags) {
            $scope.fetchData(tags);
        });
    }
    

问题是:使用$watch 还是$broadcast 会更好吗?

附录:有没有更好的方法来创建类似的指令? (例如,无需观看或广播)

【问题讨论】:

  • "一个原始的循环比较什么都不是。",fetchData 仅在数组更改时调用(topics 最大长度 = 3)
  • topicList 是否会被初始化一次,之后不再更新,还是可以随时更改?
  • 根据列表中所选主题的变化(最多 3 个)

标签: angularjs rest angularjs-directive broadcast watch


【解决方案1】:

使用 $broadcast 会很多高效。 (实际上是 $emit。)

什么是更好是一个悬而未决的问题。

$watch 不是很聪明——它必须做很多工作才能确定是否有变化。 (与 $watchCollection 的情况相同。)“我们”(AngularJS 社区)使用它是因为我们认为这些权衡是值得的。在大多数情况下,您不必经常这样做,它非常准确,而且很容易理解。它几乎遵循 AngularJS“世界”的所有原则。在一个完全模块化的世界中,这是解决问题的好方法……通常。

另一方面,当您知道确定您的数据已更改时,$watch 只是要求 AngularJS 转身猜测(好吧,努力计算)您已经知道的相同事实知道。使用消息广播效率更高——Angular 只需要遍历一小部分侦听器。它不必通过深层对象和集合进行任何基于对象/属性的键入或递归。你基本上是在为它做这项工作。

如果您这样做,请考虑使用 $emit 而不是 $broadcast。在真正的 pub/sub 中,让这些消息“冒泡”到每个作用域并没有太大优势,而且代价高昂 - 足以扼杀您刚赢得的优势。 $rootScope.$emit() 会将这些消息保持在一个级别,您可以使用 $rootScope.$on() 来监听它们。这将遍历该事件名称的单个小型侦听器集合,并完成 - 无需额外工作。

最终,决定什么是“更好”的事情会由您来决定。如果您想要效率,基于消息的模型几乎是完美的选择。如果您想要观察者的优雅,您可能需要不同的选择。

【讨论】:

  • 好的,我会说观察自己的参数的指令比听一些外部消息“更好”。那么,这里的问题是,在这种情况下,消息的效率会提高多少? topics 数组非常简单,最多可以包含 3 个字符串。 REST 操作应该不会花费太多时间(没有那么多数据),我怀疑使用 watch 或 on 哪个这样的服务没有区别..
  • 微基准测试的问题是传奇,而这恰恰是边缘。有了这样一个简单的用例,理论上您应该使用您和任何其他可能需要维护此代码的开发人员喜欢的任何模式。
  • 对于consider $emit instead of $broadcast,只想指出,在angular 1.2.7中这个fix已经大大降低了性能差异。另请参阅post 的新基准。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-12-17
  • 1970-01-01
  • 2014-03-27
  • 2017-06-12
  • 2011-12-04
  • 2010-09-28
相关资源
最近更新 更多