首页 > 代码库 > AngularJS开发者常犯的10个错误
AngularJS开发者常犯的10个错误
Mark Meyer是一个有超过一年angular.js实际开发经验的full stack软件工程师。 Mark拥有多种语言的开发经验,从基于C的服务器应用,基于Rails的web应用到使用Swift开发的IOS应用。
templates/
_login.html
_feed.html
app/
app.js
controllers/
LoginController.js
FeedController.js
directives/
FeedEntryDirective.js
services/
LoginService.js
FeedService.js
filters/
CapatalizeFilter.js
这似乎是一个显而易见的目录结构,尤其是Rails也是这么干的。然而一旦app规模开始扩张,这种结构会导致一次要打开很多目录。无论是使用Sublime,Visual Studio或是Vim结合Nerd Tree,都需要花很多时间在目录树中上下滚动。
不要按照类型组织文件,而是按照特性:
app/
app.js
Feed/
_feed.html
FeedController.js
FeedEntryDirective.js
FeedService.js
Login/
_login.html
LoginController.js
LoginService.js
Shared/
CapatalizeFilter.js
这种目录结构使得我们能够更容易地找到与某个特性相关的文件,从而加快开发进度。将.html和.js文件放在一起可能存在争议,但节省下来的时间更加宝贵。
在你准备将其部署到生产环境并压缩代码之前,一切都很正常。但如果使用UglifyJS,之前的例子会变成下面这样:
var app=angular.module("app",[]);
app.controller("MainCtrl",function(e,t){t(function(){console.log(e)},1e3)})
现在AngularJS怎么知道MainCtrl依赖谁?AngularJS提供了一种非常简单的解决方法,即将依赖作为一个字符串数组传入,数组的最后带有一个函数,所有的依赖都作为它的参数。
使用AngularJS可以很容易的将这些全局对象封装到模块中,从而使其可以像AngularJS标准模块那样被注入进去。
Underscrore.js是一个伟大的库,它以函数式的风格简化了Javascript代码,通过以下方式,你可以将其转化为一个模块:
这可能看上去十分琐碎,没什么必要,但如果你的代码正在使用use strict(而且应该使用!),那这就是必要的了。
数据也应该存储在service中,除非它们已经被绑定在$scope上了。服务本身是单例的,存在于应用程序的整个生命周期中,然而controller在应用程序的各状态间是瞬态的。如果数据被保存在控制器中,当它再次被实例化时就需要重新从某处获取数据。即使将数据存储于localStorage中,获取的速度也要比从Javascript变量中要慢一个数量级。
AngularJS在遵循单一职责原则(SRP)时运行良好。如果controller是视图和模型间的协调者,那么它所包含的逻辑就应该尽量少。这也会让测试更加简单。
下面是它们在AngularJS源码中的定义:
既然service仅仅是调用了factory函数,那二者有什么区别呢?线索在$injector.instantiate;在这个函数中,$injector在service的构造函数中创建了一个新的实例。
以下是一个例子,展示了一个service和一个factory如何完成相同的事情:
Factory在设计一个包含很多私有方法的类时也很有用:
Batarang提供了浏览模型的能力,从而能够观察到AngularJS内部是如何确定绑定到作用域上的模型的。这在观察directive和isolate scopes的绑定值时非常有用。
Batarang也提供了一个依赖图。如果用到一个未经测试的代码库时,这个依赖图能够用于决定哪些服务应该被重点关注。
最后,Batarang提供了性能分析。AngularJs性能良好,然而对于有越来越多的自定义directive和复杂逻辑的应用来说,有时候显得不够流畅。使用Batarang性能工具,能够很容易地看到在一个digest周期中哪个函数的运行时间最长。这个工具也能展示一棵完整的watch树,这在有很多watcher时很有用。
以下这个“立即执行的函数表达式(IIFE)”会打印出当前页面上所有的watcher的个数,你可以简单的将其粘贴到控制台中,观察结果。这段IIFE来源于Jared在StackOverflow上的回答:
当存在不变数据时,而你又想用AngularJS将其模版化,可以考虑使用bindonce。Bindonce是一个简单的指令,允许你使用AngularJS中的模版,但它并不会增加watch,避免了watch数量增长。
由于原型继承的特点,在父类和子类间共享数据不太重要。但如果不够小心,很容易覆盖掉父$scope的属性。
比如说,我们需要在一个导航栏上显示一个用户名,这个用户名是在登录表单中输入的。下面这种尝试应该是能工作的:
如果你选择了loginCtrl,那么你可能已经理解了原型继承是如何工作的了。
当你检索字面值时,原型链并不起作用。如果navCtrl也同时被更新的话,检索原型链是必须的;但如果值是一个对象,这就会发生。(记住,在Javascript中,函数、数组和对象都是对象)
所以为了获得预期的行为,需要在navCtrl中创建一个对象,它可以被loginCtrl引用。
这个例子有些勉强,但是当你使用directive去创建子$scope,如ngRepeat时,这个问题很容易就会产生。
不测试AngularJS应用是没有道理的。AngularJS的设计使之完全可测。依赖注入和ngMock模块就是明证。AngularJS核心团队已经开发了众多能够使测试更上一层楼的工具。
我们已经建立了Protractor,一个用于模拟用户交互的端到端的测试器,它能够帮助你验证你的AngularJS程序的健康状况。
Protractor使用Jasmine测试框架定义测试,Protractor针对不同的页面交互行为有一个非常健壮的API。
还有一些其他的端到端测试工具,但是Protractor的优势在于能够理解如何与AngularJS代码协同工作,尤其是在$digest周期中。
Karma是一个Javascript测试执行工具,它有助于工作闭环。Karma之所以能够做到这点,是因为它在指定文件被改变时就运行测试。Karma同时也能够在多个浏览器上并行执行测试。不同的设备也可以指向Karma服务器,以更好地覆盖真实的应用场景。
10. 使用jQuery
jQuery是一个神奇的库,它标准化了跨平台开发,几乎已经成为现代Web开发的必需品。不过尽管JQuery如此多的优秀特性,它的理念和AngularJS并不一致。
AngularJS是一个用来构建应用的框架,而JQuery则是一个简化“HTML文档遍历和操作、事件处理、动画和Ajax”的库。这是两者最基本的区别,AngularJS致力于应用的架构,与HTML页面无关。
为了更好的理解如何建立一个AngularJS程序,请停止使用jQuery。jQuery使开发人员以现存的HTML标准思考问题,但正如文档里所说的,“AngularJS能够让你为你的应用扩展HTML的词汇表”。
DOM操作应该只在directive中完成,但这并不意味着他们只能用jQuery封装。在你使用JQuery之前,应该先想一下这个功能是不是AngularJS已经提供了。当directives结合时能够创建强大的工具,这工作得相当好。
这一天可能会到来,一个非常棒的JQuery成为必需,但在一开始就引入它,是一个常见的错误。
原文链接:https://www.airpair.com/angularjs/posts/top-10-mistakes-angularjs-developers-make
简介
AngularJS是目前最流行的Javascript框架之一,AngularJS的目标之一是简化开发过程,这使之非常善于构建小型app原型,但它也能够用于开发功能全面的客户端应用。便于开发,特性广泛以及出众的性能使其被广泛使用,然而,大量常见陷阱也随之而来。以下这份列表摘取了一些常见的AngularJS的错误用法,尤其是在app规模扩张时。1. MVC目录结构
AngularJS,准确地说,就是一个MVC框架。它的模型并没有像backbone.js那样分工明确,但它的体系结构仍然相得益彰。当使用一个MVC框架进行开发时,普遍的做法是根据文件类型对其进行归类:templates/
_login.html
_feed.html
app/
app.js
controllers/
LoginController.js
FeedController.js
directives/
FeedEntryDirective.js
services/
LoginService.js
FeedService.js
filters/
CapatalizeFilter.js
这似乎是一个显而易见的目录结构,尤其是Rails也是这么干的。然而一旦app规模开始扩张,这种结构会导致一次要打开很多目录。无论是使用Sublime,Visual Studio或是Vim结合Nerd Tree,都需要花很多时间在目录树中上下滚动。
不要按照类型组织文件,而是按照特性:
app/
app.js
Feed/
_feed.html
FeedController.js
FeedEntryDirective.js
FeedService.js
Login/
_login.html
LoginController.js
LoginService.js
Shared/
CapatalizeFilter.js
这种目录结构使得我们能够更容易地找到与某个特性相关的文件,从而加快开发进度。将.html和.js文件放在一起可能存在争议,但节省下来的时间更加宝贵。
2. 模块(或者没有模块)
开始时将所有东西都放在主模块下是很常见的。对于小型app,刚开始并没有什么问题,但很快就变得难以管理。var app = angular.module('app',[]); app.service('MyService', function(){ //service code }); app.controller('MyCtrl', function($scope, MyService){ //controller code });在此之后,通常的办法是按对象类型来组织代码。
var services = angular.module('services',[]); services.service('MyService', function(){ //service code }); var controllers = angular.module('controllers',['services']); controllers.controller('MyCtrl', function($scope, MyService){ //controller code }); var app = angular.module('app',['controllers', 'services']);这种方式和前面第一部分所谈到的目录结构差不多:不够好。类似的,可以按特性划分,易于扩展。
var sharedServicesModule = angular.module('sharedServices',[]); sharedServices.service('NetworkService', function($http){}); var loginModule = angular.module('login',['sharedServices']); loginModule.service('loginService', function(NetworkService){}); loginModule.controller('loginCtrl', function($scope, loginService){}); var app = angular.module('app', ['sharedServices', 'login']);当开发一个大型应用程序时,不可能将所有东西都包含在一个页面上,按特性划分模块使得在应用间复用模块变得更加容易。
3. 依赖注入
依赖注入是AngularJS最好的模式之一,它使得测试更为简单,同时依赖关系更加清晰。AngularJS的注入方式非常灵活,最简单的方式只需要将被依赖者的名字传入模块的function中:var app = angular.module('app',[]); app.controller('MainCtrl', function($scope, $timeout){ $timeout(function(){ console.log($scope); }, 1000); });这里,很明显,MainCtrl依赖$scope和$timeout。
在你准备将其部署到生产环境并压缩代码之前,一切都很正常。但如果使用UglifyJS,之前的例子会变成下面这样:
var app=angular.module("app",[]);
app.controller("MainCtrl",function(e,t){t(function(){console.log(e)},1e3)})
现在AngularJS怎么知道MainCtrl依赖谁?AngularJS提供了一种非常简单的解决方法,即将依赖作为一个字符串数组传入,数组的最后带有一个函数,所有的依赖都作为它的参数。
app.controller('MainCtrl', ['$scope', '$timeout', function($scope, $timeout){ $timeout(function(){ console.log($scope); }, 1000); }]);这样压缩代码时,AngularJS就能清楚地知道如何解释这些依赖:
app.controller("MainCtrl",["$scope","$timeout",function(e,t){t(function(){console.log(e)},1e3)}])
3.1 全局依赖
在编写AngularJS应用时,经常会将一个被依赖的对象绑定到全局scope中。这意味着在任何AngularJS代码中这个依赖都是可用的,但这却破坏了依赖注入模型,并会导致一些问题,尤其在测试时。使用AngularJS可以很容易的将这些全局对象封装到模块中,从而使其可以像AngularJS标准模块那样被注入进去。
Underscrore.js是一个伟大的库,它以函数式的风格简化了Javascript代码,通过以下方式,你可以将其转化为一个模块:
var underscore = angular.module('underscore', []); underscore.factory('_', function() { return window._; //Underscore must already be loaded on the page }); var app = angular.module('app', ['underscore']); app.controller('MainCtrl', ['$scope', '_', function($scope, _) { init = function() { _.keys($scope); } init(); }]);这允许应用程序继续以AngularJS依赖注入的风格进行开发,同时在测试阶段也能将underscore替换出去。
这可能看上去十分琐碎,没什么必要,但如果你的代码正在使用use strict(而且应该使用!),那这就是必要的了。
4. Controller膨胀
Controller是AngularJS最基本的部分。一不小心就会将过多的逻辑放到其中,尤其是刚开始的时候。控制器永远都不应该去操作DOM或是持有DOM选择器,那是directive和ng-model的用武之地。同样的,业务逻辑应该存在于service中,而非controller。数据也应该存储在service中,除非它们已经被绑定在$scope上了。服务本身是单例的,存在于应用程序的整个生命周期中,然而controller在应用程序的各状态间是瞬态的。如果数据被保存在控制器中,当它再次被实例化时就需要重新从某处获取数据。即使将数据存储于localStorage中,获取的速度也要比从Javascript变量中要慢一个数量级。
AngularJS在遵循单一职责原则(SRP)时运行良好。如果controller是视图和模型间的协调者,那么它所包含的逻辑就应该尽量少。这也会让测试更加简单。
5. Service vs Factory
这两个名词让几乎每一个AngularJS开发人员在初学时都感到困惑。这真的不太应该,因为它们就是(几乎)相同事物的语法糖而已!下面是它们在AngularJS源码中的定义:
function factory(name, factoryFn) { return provider(name, { $get: factoryFn }); } function service(name, constructor) { return factory(name, ['$injector', function($injector) { return $injector.instantiate(constructor); }]); }从源代码中你可以看到,service仅仅是调用了factory函数,而factory又调用了provider函数。事实上,AngularJS也提供了一些额外的provider封装,如value,constant和decorator。但这些并没有导致类似程度的困惑,它们的文档在应用场景上说得相当清晰。
既然service仅仅是调用了factory函数,那二者有什么区别呢?线索在$injector.instantiate;在这个函数中,$injector在service的构造函数中创建了一个新的实例。
以下是一个例子,展示了一个service和一个factory如何完成相同的事情:
var app = angular.module('app',[]); app.service('helloWorldService', function(){ this.hello = function() { return "Hello World"; }; }); app.factory('helloWorldFactory', function(){ return { hello: function() { return "Hello World"; } } });当helloWorldService或helloWorldFactory被注入到controller中时,它们都有一个hello方法,返回“hello world”。service的构造函数在声明时被实例化了一次,而factory对象在每一次被注入时传递一次,但是仍然只有一个factory实例。。
既然能做相同的事,为什么需要两种不同的风格呢?相对于service,factory提供了更多的灵活性,因为它可以返回函数,这些函数之后可以被new出来。这遵循了面向对象编程中的工厂模式,工厂是一个能够创建其他对象的对象。
app.factory('helloFactory', function() { return function(name) { this.name = name; this.hello = function() { return "Hello " + this.name; }; }; });这里是一个使用了service和两个factory的controller的例子。helloFactory返回了一个函数,当被new时会设置name的值。
app.controller('helloCtrl', function($scope, helloWorldService, helloWorldFactory, helloFactory) { init = function() { helloWorldService.hello(); //'Hello World' helloWorldFactory.hello(); //'Hello World' new helloFactory('Readers').hello() //'Hello Readers' } init(); });在开始时,最好只使用service。
Factory在设计一个包含很多私有方法的类时也很有用:
app.factory('privateFactory', function(){ var privateFunc = function(name) { return name.split("").reverse().join(""); //reverses the name }; return { hello: function(name){ return "Hello " + privateFunc(name); } }; });通过这个例子,可以让privateFactory的公有API无法直接访问privateFunc,这种模式在service中是可以做到的,但在factory中更加直观。
6. 没有使用Batarang
Batarang是一个出色的Chrome插件,用来开发和调试AngularJS应用。Batarang提供了浏览模型的能力,从而能够观察到AngularJS内部是如何确定绑定到作用域上的模型的。这在观察directive和isolate scopes的绑定值时非常有用。
Batarang也提供了一个依赖图。如果用到一个未经测试的代码库时,这个依赖图能够用于决定哪些服务应该被重点关注。
最后,Batarang提供了性能分析。AngularJs性能良好,然而对于有越来越多的自定义directive和复杂逻辑的应用来说,有时候显得不够流畅。使用Batarang性能工具,能够很容易地看到在一个digest周期中哪个函数的运行时间最长。这个工具也能展示一棵完整的watch树,这在有很多watcher时很有用。
7. 过多的watcher
在上一点中提到,AngularJS性能良好。由于要在一个digest周期中完成脏数据检查,一旦watcher的数量增长到大约2000时,这个周期就会产生显著的性能问题。(2000这个数字并不一定会造成性能大幅下降,但这是一个不错的经验数值。在AngularJS 1.3 release版本中,已经有一些允许严格控制digest周期的改动了,Aaron Gray有一篇在这个问题上的很好的文章。)以下这个“立即执行的函数表达式(IIFE)”会打印出当前页面上所有的watcher的个数,你可以简单的将其粘贴到控制台中,观察结果。这段IIFE来源于Jared在StackOverflow上的回答:
(function () { var root = $(document.getElementsByTagName('body')); var watchers = []; var f = function (element) { if (element.data().hasOwnProperty('$scope')) { angular.forEach(element.data().$scope.$$watchers, function (watcher) { watchers.push(watcher); }); } angular.forEach(element.children(), function (childElement) { f($(childElement)); }); }; f(root); console.log(watchers.length); })();通过这个方式得到watcher的数量,结合Batarang性能部分的watch树,应该可以发现哪里存在重复代码,或着哪些不变数据拥有watch。
当存在不变数据时,而你又想用AngularJS将其模版化,可以考虑使用bindonce。Bindonce是一个简单的指令,允许你使用AngularJS中的模版,但它并不会增加watch,避免了watch数量增长。
8. 确定$scope的范围
Javascript基于原型的继承与面向对象中基于类的继承有着微妙的区别。这通常不是什么问题,但在使用$scope时就会表现出来。在AngularJS中,每个$scope都会继承父$scope,最高层是$rootScope。($scope用在directive中时有些不同,isolate scopes只继承显式声明的属性。)由于原型继承的特点,在父类和子类间共享数据不太重要。但如果不够小心,很容易覆盖掉父$scope的属性。
比如说,我们需要在一个导航栏上显示一个用户名,这个用户名是在登录表单中输入的。下面这种尝试应该是能工作的:
<div ng-controller="navCtrl"> <span>{{user}}</span> <div ng-controller="loginCtrl"> <span>{{user}}</span> <input ng-model="user"></input> </div> </div>提问:在text input中设置了user的ng-model,当用户在其中输入内容时,哪个模版会被更新?navCtrl还是loginCtrl,还是都会?
如果你选择了loginCtrl,那么你可能已经理解了原型继承是如何工作的了。
当你检索字面值时,原型链并不起作用。如果navCtrl也同时被更新的话,检索原型链是必须的;但如果值是一个对象,这就会发生。(记住,在Javascript中,函数、数组和对象都是对象)
所以为了获得预期的行为,需要在navCtrl中创建一个对象,它可以被loginCtrl引用。
<div ng-controller="navCtrl"> <span>{{user.name}}</span> <div ng-controller="loginCtrl"> <span>{{user.name}}</span> <input ng-model="user.name"></input> </div> </div>现在,由于user是一个对象,原型链就会起作用,navCtrl模版和$scope会同loginCtrl的一起被更新。
这个例子有些勉强,但是当你使用directive去创建子$scope,如ngRepeat时,这个问题很容易就会产生。
9. 手工测试
由于TDD可能不是每个开发人员都喜欢的开发方式,因此当开发人员检查代码是否工作或是否影响了其它东西时,他们会做手工测试。不测试AngularJS应用是没有道理的。AngularJS的设计使之完全可测。依赖注入和ngMock模块就是明证。AngularJS核心团队已经开发了众多能够使测试更上一层楼的工具。
9.1 Protractor
单元测试是测试套的基础,但考虑到app的日益复杂,集成测试被迫更加现实。幸运的是,AngularJS的核心团队已经提供了必要的工具。我们已经建立了Protractor,一个用于模拟用户交互的端到端的测试器,它能够帮助你验证你的AngularJS程序的健康状况。
Protractor使用Jasmine测试框架定义测试,Protractor针对不同的页面交互行为有一个非常健壮的API。
还有一些其他的端到端测试工具,但是Protractor的优势在于能够理解如何与AngularJS代码协同工作,尤其是在$digest周期中。
9.2 Karma
一旦我们用Protractor完成了集成测试的编写工作,接下去就是执行测试了。等待测试执行,尤其是集成测试,对每个开发人员来说都是痛苦的事情。AngularJS的核心团队感同身受,于是开发了Karma。Karma是一个Javascript测试执行工具,它有助于工作闭环。Karma之所以能够做到这点,是因为它在指定文件被改变时就运行测试。Karma同时也能够在多个浏览器上并行执行测试。不同的设备也可以指向Karma服务器,以更好地覆盖真实的应用场景。
10. 使用jQuery
jQuery是一个神奇的库,它标准化了跨平台开发,几乎已经成为现代Web开发的必需品。不过尽管JQuery如此多的优秀特性,它的理念和AngularJS并不一致。AngularJS是一个用来构建应用的框架,而JQuery则是一个简化“HTML文档遍历和操作、事件处理、动画和Ajax”的库。这是两者最基本的区别,AngularJS致力于应用的架构,与HTML页面无关。
为了更好的理解如何建立一个AngularJS程序,请停止使用jQuery。jQuery使开发人员以现存的HTML标准思考问题,但正如文档里所说的,“AngularJS能够让你为你的应用扩展HTML的词汇表”。
DOM操作应该只在directive中完成,但这并不意味着他们只能用jQuery封装。在你使用JQuery之前,应该先想一下这个功能是不是AngularJS已经提供了。当directives结合时能够创建强大的工具,这工作得相当好。
这一天可能会到来,一个非常棒的JQuery成为必需,但在一开始就引入它,是一个常见的错误。
结论
AngularJS是一个伟大的框架,在社区中不断演进。符合习惯的AngularJS仍然是一个不断发展的概念,但希望通过遵循以上谈到的这些约定,能够避免遇到开发大规模AngularJS应用时的一些大的陷阱。原文链接:https://www.airpair.com/angularjs/posts/top-10-mistakes-angularjs-developers-make
AngularJS开发者常犯的10个错误
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。