现在,我知道全局变量是一种反模式,在Angular世界中可能比其他地方更多……但是,我遇到了一个用例,我倾向于违反规则……
我已经阅读了这里的评论,并且非常同意所有指出我的想法所代表的反角度主义的海报以及它通常的反模式……
Angular JS – Make service globally accessible from controllers and view
但是,现在对于我的用例,我有一个$theme服务,它包含很多变量和常量,比如图像和字符串的路径.
我们还有一个组件框架,应用程序设计人员可以通过指令访问它们,允许我们的大多数应用程序只使用标记指令形式的内部框架构建.
我可以为每个需求制定指令,但是它会牺牲视图和主题之间低耦合的灵活性,允许开发人员直接在视图中访问$theme服务,而不必(重新)编写控制器(甚至为所有东西创建控制器或实现新的指令,它将允许它们纯粹在内部框架可用的标记中工作.基本上我想让应用程序设计人员能够纯粹在标记中工作.
我们还制作了包含对ngResource的引用的指令,并公开了当前$scope上的资源方法,以及将当前$scope绑定到$stateParam服务上的变量等的指令,希望你能得到图片. ..
例如
<h1>{{$root.$theme.NAME}}"</h1>
<img my-src="$root.$theme.logo.url" />
而不是许多代码与控制器和指令……
<my-theme-name />
<h1 my-theme-name />
<my-theme-logo />
<img my-theme-logo />
这两种方法之间的区别在于指令附加了主标记,它纯粹是装饰器,在前一种情况下,指令是主标记,指令模板将确定生成的主标记.在我们使用指令纯粹作为装饰者而非信息专家的方法中,略微不同,产生了更大程度的灵活性.
然而,不是必须一起编写指令,也许是为了纯粹添加到单个主题的东西,只是在单个应用程序中使用,在这种情况下,在$theme服务中添加支持似乎是错误的方法…
但是,采用严格的自定义指令驱动方法,它可能允许我们更容易地移植到例如Angular2甚至是其他东西,只需构建一个适配器或转换器,而不必重写任何标记,但简单地将指令重新连接到新库中编写的新控制器和处理程序.
所以,回到我的问题,如果我们围绕这个警告进行测试,它是一种可行的方法,还是走向全球变量地狱的一条滑路,很快我们就会用大量的东西污染我们的根源,因为它是简单的方法？
_____ 2016年5月7日更新_____
好吧,当我突然被迫将我的$fileSaver服务放在全局范围内时,我决定不使我的主题服务全局可用,这表明我对“范围 – 蠕变”的恐惧是有效的,而是我决定实现一个< ; my-injector my-name =“$theme”/>允许应用程序设计者以声明方式导入服务的指令,该指令使myName属性中指定的注入目标在当前作用域中可用.
它允许应用程序设计人员在范围内的任何位置使用服务,如下所示：
<my-injector my-name="$theme" />
<img ng-src="$theme.logo.url" />
我想过创建差异便利指令,例如一些应用程序设计师可能会找到< my-import my-name“$theme”/>更直观,但这是一个不同的讨论……
最佳答案 避免使用rootScope并不是绝对必要的.从
Angular FAQ开始,我强调：
Of course, global state sucks and you should use $rootScope sparingly, like you would (hopefully) use with global variables in any language. In particular, don’t use it for code, only data. If you’re tempted to put a function on $rootScope, it’s almost always better to put it in a service that can be injected where it’s needed, and more easily tested.
Conversely, don’t create a service whose only purpose in life is to store and return bits of data.
由于你的主题似乎主要是数据,我说为什么不使用root？如果它确实包含函数,是否可以拆分它？我无法为你决定,我还没有看到你真正要做的事……
