Angularjs pubsub vs $ broadcast

Question

我一直在阅读Angularjs的事件传递，我不相信使用$ broadcast是一个好主意。

像这样的博客one主张习惯使用$ on，即使它“感觉有点矫枉过正。”

我的困惑是实现使用范围的深度优先遍历并查找订阅者，这使得事件的速度取决于您的树结构。 以下是角度中的一些代码：

// Insanity Warning: scope depth-first traversal
// yes, this code is a bit crazy, but it works and we have tests to prove it!
// this piece should be kept in sync with the traversal in $digest
if (!(next = (current.$$childHead || (current !== target && current.$$nextSibling)))) {
   while(current !== target && !(next = current.$$nextSibling)) {
     current = current.$parent;
   }
}

此外，您似乎可以使用这些方法破解依赖注入。

替代方案只是一种缓存事件类型和回调的服务，并直接调用它们。这要求您清理订阅以避免泄漏。

我的问题是，对于$ broadcast / $范式的动机，我有什么遗漏吗？或者在更传统的pubsub上使用它有什么好处？

如果我对自己的问题不够清楚，请告诉我，谢谢你的时间。

Answer 1

我认为你没有遗漏任何东西。您已经成功地概述了每种方法的优缺点。

$broadcast / $on方法不要求您取消订阅，但它广播到所有范围并不是非常有效。它的进入门槛也很低。您不需要注入任何服务，也不需要创建它们。他们向所有人播放，因此这是一种更简单的方法。

发布/订阅方法更直接。只有订阅者才能获得事件，因此不会让系统中的每个范围都能使其生效。但是，它更复杂，因为您需要使用回调处理程序编写服务，并且必须记住取消订阅。在我看来，记住取消订阅是非常巨大的。如果你没有做到这一点，你会得到内存泄漏。在3个月内出现问题之前你不会知道它。

我可以看到为什么内置方法是$broadcast。

Answer 2

我在看同样的问题。特别是如何允许服务在不访问$ rootScope的情况下广播和订阅事件（由于某些原因而不好）。 我从这里使用了非常优秀的js-signals实现： http://millermedeiros.github.io/js-signals/ 并把它包裹成一个有角度的服务。

github要点：https://gist.github.com/anonymous/b552c7fafa77427e6d06