使用$ rootScope。$ broadcast（）还是不错的做法？

Question

在使用事件时，我在灵活性和代码缩减方面看到了很多优点（您不必在多个组件层之间绑定值），但它也可能使调试复杂化。

我的问题

在AngularJS 1.6中使用$ rootScope。$ broadcast（）仍然是对模型变化作出反应的好习惯吗？

Answer 1

在angluar框架本身，只有很少的事件。因此，您可以了解为什么不严重依赖事件，肯定有其他更好的方法来做到这一点。

您可能会遇到像

这样的问题

基于事件的方法可能会非常混乱，无法跟踪，维护和调试。它使它非常异步，没有真正简单的方法来跟踪应用程序的流程。

在broadcast方法之后，在团队环境中工作会非常困难。并且您的代码可能/可能在大多数情况下容易出错。

此外，当您需要将事件名称向下调度到所有子范围时，极少数情况下，如果有，您必须知道

当您在控制器的$ scope上添加事件侦听器时，当控制器被销毁时（您离开页面或关闭某个部分），侦听器也会被销毁。当您将其添加到$rootScope时，当您离开控制器时，侦听器将保持并保持触发状态。因此，您必须手动取消注册，或者是安全的，而不是将其添加到$rootScope。

Answer 2

我不能对所有有角度的开发者说，但我会尝试使用自己的经验。 使用$ broadcast特别是$ rootScope。$ broadcast会产生一些负面的副作用。

1. 性能。 $ rootScope广播将遍历每个组件。如果你需要很多观察者，它会上升并重新上升可能导致冻结的消化。

2. 可读性。事件会破坏您的代码的可读性。

3. 调试。事件驱动模型有点难以维护和调试。您应该非常了解您的解决方案以找到订阅者并对其进行调试。

而角度让你有办法避免这种情况。

如果您需要对子节点（范围，控制器等）做出反应，您可以传递模型并在控制器上使用$ onChanges方法

  

$ onChanges？（changesObj：{[property：string]：IChangesObject}）：void;

如果需要对父节点做出反应，请将方法传递给子节点，并在发生更改时调用它。

当可能使用$ broadcast时，只有一个原因 - 当您需要对兄弟节点做出反应时。广播事件比制作更新链更容易 - ＆gt;更新 - ＆gt;更新。

使用$ broadcast在开始时是一个更简单的解决方案，但它会达到您的开发性能。所以它只是您准备支付的价格和当前需求的一米。

希望这有帮助。