AngularJS开发人员最常犯的10个错误
簡介
AngularJS是目前最為活躍的Javascript框架之一，AngularJS的目標之一是簡化開發過程，
這使得AngularJS非常善于構建小型app原型，但AngularJS對于全功能的客戶端應用程序同樣
強大，它結合了開發簡便，特性廣泛和出眾的性能，使其被廣泛使用。然而，大量使用也會產生
諸多誤區。以下這份列表摘取了常見的一些AngularJS的錯誤用法，尤其是在app開發過程中。
1. MVC目錄結構
AngularJS，直白地說，就是一個MVC框架。它的模型并沒有像backbone.js框架那樣定義的
如此明確，但它的體系結構卻恰如其分。當你工作于一個MVC框架時，普遍的做法是根據文件類
型對其進行歸類：
看起來，這似乎是一個顯而易見的結構，更何況Rails也是這么干的。然而一旦app規模開始
擴張，這種結構會導致你一次需要打開很多目錄，無論你是使用sublime，Visual Studio或是Vim
結合Nerd Tree，你都會投入很多時間在目錄樹中不斷地滑上滑下。
與按照類型劃分文件不同，取而代之的，我們可以按照特性劃分文件：
這種目錄結構使得我們能夠更容易地找到與某個特性相關的所有文件，繼而加快我們的開發
進度。盡管將.html和.js文件置于一處可能存在爭議，但節省下來的時間更有價值。
2. 模塊
將所有東西都一股腦放在主模塊下是很常見的，對于小型app，剛開始并沒有什么問題，然而
很快你就會發現坑爹的事來了。
在此之后，一個常見的策略是對相同類型的對象歸類。
這種方式和前面第一部分所談到的目錄結構差不多：不夠好。根據相同的理念，可以按照特
性歸類，這會帶來可擴展性。
當我們開發一個大型應用程序時，可能并不是所有東西都包含在一個頁面上。將同一類特性
置于一個模塊內，能使跨app間重用模塊變得更容易。
3. 依賴注入
依賴注入是AngularJS最好的模式之一，它使得測試更為簡單，并且依賴任何指定對象都很
明確。AngularJS的注入方式非常靈活，最簡單的方式只需要將依賴的名字傳入模塊的function中
即可：
這里，很明顯，MainCtrl依賴$scope和$timeout。
直到你準備將其部署到生產環境并希望精簡代碼時，一切都很美好。如果使用UglifyJS，之前
的例子會變成下面這樣：
現在AngularJS怎么知道MainCtrl依賴誰？AngularJS提供了一種非常簡單的解決方法，即將
依賴作為一個數組傳入，數組的最后一個元素是一個函數，所有的依賴項作為它的參數。
這樣做能夠精簡代碼，并且AngularJS知道如何解釋這些明確的依賴：
3.1 全局依賴
在編寫AngularJS程序時，時常會出現這種情況：某個對象有一個依賴，而這個對象又將其自
身綁定在全局scope上，這意味著在任何AngularJS代碼中這個依賴都是可用的，但這卻破壞了依
賴注入模型，并會導致一些問題，尤其體現在測試過程中。
使用AngularJS可以很容易的將這些全局依賴封裝進模塊中，所以它們可以像AngularJS標準
模塊那樣被注入進去。
Underscrore.js是一個很贊的庫，它可以以函數式的風格簡化Javascript代碼，通過以下方式
，你可以將其轉化為一個模塊：
這樣的做法允許應用程序繼續以AngularJS依賴注入的風格進行開發，同時在測試階段也能
將underscore交換出去。
這可能看上去十分瑣碎，沒什么必要，但如果你的代碼中正在使用use strict（而且必須
使用），那這就是必要的了。
4. 控制器膨脹
控制器是AngularJS的肉和土豆，一不小心就會將過多的邏輯加入其中，尤其是剛開始的時候
。控制器永遠都不應該去操作DOM，或是持有DOM選擇器，那是我們需要使用指令和ng-model
的地方。同樣的，業務邏輯應該存在于服務中，而非控制器。
數據也應該存儲在服務中，除非它們已經被綁定在$scope上了。服務本身是單例的，在應用
程序的整個生命周期都存在，然而控制器在應用程序的各狀態間是瞬態的。如果數據被保存在控
制器中，當它被再次實例化時就需要重新從某處獲取數據。即使將數據存儲于localStorage中，檢
索的速度也要比Javascript變量慢一個數量級。
AngularJS在遵循單一職責原則（SRP）時運行良好，如果控制器是視圖和模型間的協調者
，那么它所包含的邏輯就應該盡量少，這同樣會給測試帶來便利。
5. Service vs Factory
幾乎每一個AngularJS開發人員在初學時都會被這些名詞所困擾，這真的不太應該，因為它們
就是針對幾乎相同事物的語法糖而已！
以下是它們在AngularJS源代碼中的定義：
從源代碼中你可以看到，service僅僅是調用了factory函數，而后者又調用了provider函數。事
實上，AngularJS也為一些值、常量和裝飾提供額外的provider封裝，而這些并沒有導致類似的
困惑，它們的文檔都非常清晰。
由于service僅僅是調用了factory函數，這有什么區別呢？線索在$injector.instantiate：在這個
函數中，$injector在service的構造函數中創建了一個新的實例。
以下是一個例子，展示了一個service和一個factory如何完成相同的事情：
當helloWorldService或helloWorldFactory被注入到控制器中，它們都有一個hello方法，
返回”hello world”。service的構造函數在聲明時被實例化了一次，同時factory對象在每一次被注入
時傳遞，但是仍然只有一個factory實例。所有的providers都是單例。
既然能做相同的事，為什么需要兩種不同的風格呢？相對于service，factory提供了更多的靈
活性，因為它可以返回函數，這些函數之后可以被新建出來。這迎合了面向對象編程中工廠模式
的概念，工廠可以是一個能夠創建其他對象的對象。
這里是一個控制器示例，使用了service和兩個factory，helloFactory返回了一個函數，當新建
對象時會設置name的值。
在初學時，最好只使用service。
Factory在設計一個包含很多私有方法的類時也很有用：
通過這個例子，我們可以讓privateFactory的公有API無法訪問到privateFunc方法，這種模式
在service中是可以做到的，但在factory中更容易。
6. 沒有使用Batarang
Batarang是一個出色的Chrome插件，用來開發和測試AngularJS app。
Batarang提供了瀏覽模型的能力，這使得我們有能力觀察AngularJS內部是如何確定綁定到作
用域上的模型的，這在處理指令以及隔離一定范圍觀察綁定值時非常有用。
Batarang也提供了一個依賴圖， 如果我們正在接觸一個未經測試的代碼庫，這個依賴圖就很
有用，它能決定哪些服務應該被重點關照。
最后，Batarang提供了性能分析。Angular能做到開包即用，性能良好，然而對于一個充滿了
自定義指令和復雜邏輯的應用而言，有時候就不那么流暢了。使用Batarang性能工具，能夠直接
觀察到在一個digest周期中哪個函數運行了最長時間。性能工具也能展示一棵完整的watch樹，在
我們擁有很多watcher時，這很有用。
7. 過多的watcher
在上一點中我們提到，AngularJS能做到開包即用，性能良好。由于需要在一個digest周期中
完成臟數據檢查，一旦watcher的數量增長到大約2000時，這個周期就會產生顯著的性能問題。
（2000這個數字不能說一定會造成性能大幅下降，但這是一個不錯的經驗數值。在AngularJS 1.3
release版本中，已經有一些允許嚴格控制digest周期的改動了，Aaron Gray有一篇很好的文章對
此進行解釋。）
以下這個“立即執行的函數表達式(IIFE)”會打印出當前頁面上所有的watcher的個數，你可以簡
單的將其粘貼到控制臺中，觀察結果。這段IIFE來源于Jared在StackOverflow上的回答：
通過這個方式得到watcher的數量，結合Batarang性能板塊中的watch樹，應該可以看到哪里
存在重復代碼，或著哪里存在不變數據同時擁有watch。
當存在不變數據，而你又想用AngularJS將其模版化，可以考慮使用bindonce。Bindonce是
一個簡單的指令，允許你使用AngularJS中的模版，但它并不會加入watch，這就保證了watch數
量不會增長。
8. 限定$scope的范圍
Javascript基于原型的繼承與面向對象中基于類的繼承有著微妙的區別，這通常不是什么問題
，但這個微妙之處在使用$scope時就會表現出來。在AngularJS中，每個$scope都會繼承
父$scope，最高層稱之為$rootScope。（$scope與傳統指令有些不同，它們有一定的作用范圍i
，且只繼承顯式聲明的屬性。）
由于原型繼承的特點，在父類和子類間共享數據不太重要，不過如果不小心的話，也很容易
誤用了一個父$scope的屬性。
比如說，我們需要在一個導航欄上顯示一個用戶名，這個用戶名是在登錄表單中輸入的，下
面這種嘗試應該是能工作的：
那么問題來了……：在text input中設置了user的ng-model，當用戶在其中輸入內容時，哪個
模版會被更新？navCtrl還是loginCtrl，還是都會？
如果你選擇了loginCtrl，那么你可能已經理解了原型繼承是如何工作的了。
當你檢索字面值時，原型鏈并不起作用。如果navCtrl也同時被更新的話，檢索原型鏈是必
須的；但如果值是一個對象，這就會發生。（記住，在Javascript中，函數、數組和對象都是對象
）
所以為了獲得預期的行為，需要在navCtrl中創建一個對象，它可以被loginCtrl引用。
現在，由于user是一個對象，原型鏈就會起作用，navCtrl模版和$scope和loginCtrl都會被
更新。
這看上去是一個很做作的例子，但是當你使用某些指令去創建子$scope，如ngRepeat時，這
個問題很容易就會產生。
9. 手工測試
由于TDD可能不是每個開發人員都喜歡的開發方式，因此當開發人員檢查代碼是否工作或是
否影響了其它東西時，他們會做手工測試。
不去測試AngularJS app，這是沒有道理的。AngularJS的設計使得它從頭到底都是可測試的
，依賴注入和ngMock模塊就是明證。AngularJS核心團隊已經開發了眾多能夠使測試更上一層樓
的工具。
9.1 Protractor
單元測試是一個測試工作的基礎，但考慮到app的日益復雜，集成測試更貼近實際情況。幸運
的是，AngularJS的核心團隊已經提供了必要的工具。
我們已經建立了Protractor，一個端到端的測試器用以模擬用戶交互，這能夠幫助你驗證你
的AngularJS程序的健康狀況。
Protractor使用Jasmine測試框架定義測試，Protractor針對不同的頁面交互行為有一個非常健
壯的API。
我們還有一些其他的端到端測試工具，但是Protractor的優勢是它能夠理解如何與AngularJS
代碼協同工作，尤其是在$digest周期中。
9.2 Karma
一旦我們用Protractor完成了集成測試的編寫工作，接下去就是執行測試了。等待測試執行，
尤其是集成測試，對每個開發人員都是一種淡淡的憂傷。AngularJS的核心團隊也感到極為蛋疼
于是他們開發了Karma。
Karma是一個測試器，它有助于關閉反饋回路。Karma之所以能夠做到這點，是因為它在指
定文件被改變時就運行測試。Karma同時也會在多個瀏覽器上運行測試，不同的設備也可以指
向Karma服務器，這樣就能夠更好地覆蓋真實世界的應用場景。
10. 使用jQuery
jQuery是一個酷炫的庫，它有標準化的跨平臺開發，幾乎已經成為了現代化Web開發的必
需品。不過盡管JQuery如此多的優秀特性，它的理念和AngularJS并不一致。
AngularJS是一個用來建立app的框架，而JQuery則是一個簡化“HTML文檔操作、事件處理、
動畫和Ajax”的庫。這是兩者最基本的區別，AngularJS致力于程序的體系結構，與HTML頁面無關
。
為了更好的理解如何建立一個AngularJS程序，請停止使用jQuery。JQuery使開發人員以現
存的HTML標準思考問題，但正如文檔里所說的，“AngularJS能夠讓你在應用程序中擴張HTML這
個詞匯”。
DOM操作應該只在指令中完成，但這并不意味著他們只能用JQuery封裝。在你使用JQuery
之前，你應該總是去想一下這個功能是不是AngularJS已經提供了。當指令互相依賴時能夠創建強
大的工具，這確實很強大。
但一個非常棒的JQuery是必需品時，這一天可能會到來，但在一開始就引入它，是一個常見
的錯誤。
結論
AngularJS是一卓越的框架，在社區的幫助下始終在進步。雖說AngularJS仍然是一個不斷發
展的概念，但我希望人們能夠遵循以上談到的這些約定，避免開發AngularJS應用所遇到的那些
問題。
轉載于:https://www.cnblogs.com/ndos/p/8331717.html
總結
以上是生活随笔為你收集整理的AngularJS开发人员最常犯的10个错误的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： JVM内存结构与GC
- 下一篇： JavaScript事件使用指南