我一直在努力按照AngularJS的正确方式去做事情,目前正在阅读如何让控制器观察Angular服务中保存的模型变化的相关内容。
有些网站表示,在控制器中使用$watch是绝对错误的:
不要在控制器中使用$watch。它很难测试,并且在几乎所有情况下都是完全不必要的。使用作用域上的方法来更新被$watch修改的值。
其他人则认为只要清理干净就可以使用$watch:
$watch函数本身返回一个函数,该函数将在调用时取消$watch的绑定。因此,在不再需要$watch时,我们只需调用$watch返回的函数。
有SO问题和其他知名网站明确表示,在控制器中使用$watch是注意到angular-service维护的模型变化的好方法。
https://github.com/angular/angular.js/wiki/Best-Practices网站,我认为我们可以更加重视它,直言$ scope.$watch应该替代事件的需要。然而,对于处理100个以上模型和REST端点的复杂SPA,选择使用$watch避免具有$broadcast/$emit
事件可能会产生大量的观察者。另一方面,如果我们不使用$watch,对于非平凡的应用程序,我们最终会得到许多事件纷乱。
这是一个失败/失败的情况吗?事件和观察之间是一个虚假的选择吗?我知道您可以在许多情况下使用双向绑定,但有时您只需要需要一种监听更改的方式。
编辑
Ilan Frumer的评论让我重新考虑了我的问题,所以也许不仅仅是问在控制器中使用$watch是否主观上好/坏,让我这样提问:
哪种实现方式可能首先创建性能瓶颈?将控制器设置为监听事件(必须已经广播/发出),还是在控制器中设置$watch。请记住,这是一个大型应用程序。
哪种实现方式首先会带来维护方面的麻烦:$watch还是事件?可以说无论哪种方式都存在耦合(紧密/松散)...事件观察者需要知道要监听什么,而对外部值(例如MyDataService.getAccountNumber())进行$watch需要了解其$scope之外发生的事情。
** 一年后的编辑 **
Angular自我提高和改进很多,但我仍然得到了+1,所以我想提一下,在查看angular团队的代码时,我发现当涉及到控制器中的观察者(或者有一个被销毁的作用域的指令)时,存在一种模式:
$scope.$on('$destroy', $scope.$watch('scopeVariable', functionIWantToCall));这个代码段的作用是获取 $watch 函数返回的函数(可以调用以取消监视器),并将其提供给控制器销毁时的事件处理程序。这会自动清除监视器。
无论在控制器中使用监视器是否是一种代码异味,如果您使用它们,我相信 Angular 团队对此模式的使用应该作为如何使用它们的强烈推荐。
谢谢!
$scope.$on('$stateChangeStart', fn()...)
监听事件。我没有找到一种干净的方法来使用数据绑定来注意服务中的更改,该服务触发状态更改,因为数据绑定发生在首先,而状态更改尚未发生。尽管听起来很丑陋,但最简单的解决方法是监听$stateChangeStart
事件,然后启动$digest
... 恐怖 - tengen