伯樂線上導讀：本文由 機器human 編譯自 Mark Rajcok 在 StackOverflow 的同名問答題《How do I “think in Angular.js” if I have a jQuery background?》。下面是 Mark Rajcok 的提問：
“我可以熟練使用jQuery進行客戶端應用的開發，但是現在我希望開始使用Angular.js。哪位能描述一下這個過程中必要的模式變化嗎？希望您的答案能夠圍繞下面這些具體的問題：
1. 我如何對客戶端web應用進行不同方式的架構和設計？它們之間最大的區別是什麼？（譯者注：指jQuery和Angular.js）
2. 有什麼是我不該做或者不該使用的；而又有什麼是我應該做或者應該使用的呢？
3. 有沒有一些服務端的考量/約束呢？
我在尋找的就是一個關於jQuery和Angular.js之間的詳細的比較。”
下面是來自 Josh David Miller 的最佳回答：
1. 絕不要先設計你的頁面，然後用DOM操作去改變它
在jQuery中，你會先設計一個頁面，然後讓它變得動態化。這是因為jQuery是為了擴充套件而設計的，並在這個前提下變得越來越臃腫。
但是在Angular.js中， 你必須從一開始就在腦子裡掛著架構的弦。不要一開始就想著“我有這樣一個DOM，我想讓它做X”， 你必須從你要完成的目標開始思考，然後設計你的應用， 最後才是設計你的檢視。
2. 不要用 Angular.js 擴充套件 jQuery
類似地，不要一開始就帶著這樣的想法：jQuery可以完成X，Y，Z，所以我只要在其上為模型和控制器新增Angular.js就行了。在起步階段這確實很容易勾引你，這也是為什麼我總是推薦Angular.js新手根本不要使用jQuery，至少要在他們習慣了“angular 方式”之後。
我在這裡（譯者注：指stackoverflow）和郵件列表上看到過很多開發者，他們用150或者200行程式碼的jQuery外掛，然後利用一堆讓人困惑的複雜的回撥和$apply與Angular.js粘合起來建立這些詳盡的解決方案；最終確實可以跑起來！ 但是其實這個問題在大多數情況下，我們可以用一小段Angular.js程式碼來重寫jQuery外掛即可，而這種方式會讓一切剎那間簡單明瞭可理解。
我覺得這類問題的底線是：當你在解決問題時，首先利用“Angular.js思想”去做；如果你不能想出一個方案，那麼就在社群裡詢問；如果還是沒有簡單的解決方法，那麼再請隨意使用jQuery吧。但是注意，千萬別讓jqeury成為你的柺杖，不然你將永遠無法真正精通Angular.js。
3. 永遠根據架構去思考
首先你要知道，單頁面結構也是應用。它不是網頁。所以我們需要有服務端開發者思想加上客戶端開發者思想。 我們必須考慮如何將我們的應用拆分為獨立，可擴充套件，可測試的元件。
那麼你要怎麼做呢？你如何做到利用“angualrjs思想”呢？這裡有一些普遍的原則，與jQuery作為比照。
檢視是“正式記錄”
在jQuery中，我們通過程式設計方式來改變檢視。我們可以像下面這樣通過ul標籤來定義一個下拉選單：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
<ul class="main-menu"> <li class="active"> <a href="#/home">Home</a> </li> <li> <a href="#/menu1">Menu 1</a> <ul> <li><a href="#/sm1">Submenu 1</a></li> <li><a href="#/sm2">Submenu 2</a></li> <li><a href="#/sm3">Submenu 3</a></li> </ul> </li> <li> <a href="#/home">Menu 2</a> </li> </ul> |
在jQuery中，根據我們應用的邏輯，可以用類似下面的語句來啟用它。
|
1 |
$('.main-menu').dropdownMenu(); |
當我們只是看著檢視的時候，不會立刻看出它的功能。對於小應用而言，這樣是沒問題的。但是對於大型的應用，情況就一下子變得令人困惑並且難以維護。
但是在Angular.js中，檢視是基於檢視的功能的正式記錄。我們的ul是像下面這樣宣告的：
|
1 2 3 |
<ul class="main-menu" dropdown-menu> ... </ul> |
這兩者其實做了同樣的事情，但是在Angular.js的版本中，任何看到這個模板的人都知道將要發生什麼。不論何時，開發團隊裡有任何新的開發人員加入，她可以一眼看出有一個叫做dropdownMenu的指令作用在檢視上；她根本不需要憑直覺猜測或者研究下程式碼才找到正確的答案。檢視本身就告訴我們將會發生什麼了。清晰多了。
angualrjs的新手經常會問這樣一個問題： 我如何找到某一類所有的連結並且給它們新增一個指令呢？當看到我們回覆的時候小夥伴都震驚了：壓根別去這樣做。但是勸你不要這樣做的原因是，這樣做就像是一半jQuery，一半angulrjs，而這真心很糟。這裡的問題是，開發者想在angualrjs的情境中使用jQuery方式。而這絕對不會玩得轉。檢視是正式記錄。超出指令的範圍（這點下文會談論更多），你絕不要去改變DOM。而且指令是應用在檢視中的，目的自然也一目瞭然。
記住：不要先設計再修飾。你必須先進行架構，然後再考慮設計。
資料繫結
這是Angular.js目前最酷的特性之一，並且秒殺我前文提到的各種需要的DOM操作。不需要你自己動手，Angular.js將自動更新你的檢視有木有!
在jQuery裡， 我們響應事件並更新內容，大概是這個樣子：
|
1 2 3 4 5 6 |
$.ajax({ url: '/myEndpoint.json', success: function ( data, status ) { $('ul#log').append('<li>Data Received!</li>'); } }); |
檢視則看上去是這樣的：
|
1 2 |
<ul class="messages" id="log"> </ul> |
除了關注點混合的問題，這裡同樣有之前提到的表徵目的的問題。更重要的是，我們不得不手動引用並更新dom節點。並且如果我們想要刪除一個日誌，我們不得不再次對dom程式設計操作。我們怎樣才能拋開dom來測試邏輯呢？還有，如果我們希望改變展現呢？
真是讓人凌亂。。。
但是在Angular.js中，我們可以這樣做：
|
1 2 3 |
$http( '/myEndpoint.json' ).then( function ( response ) { $scope.log.push( { msg: 'Data Received!' } ); }); |
我們的檢視看上去是這樣的：
|
1 2 3 |
<ul class="messages"> <li ng-repeat="entry in log">{{ entry.msg }}</li> </ul> |
但是考慮到剛才提到的問題，我們的檢視看上去可以是這樣的：
|
1 2 3 4 5 |
<div class="messages"> <div class="alert" ng-repeat="entry in log"> {{ entry.msg }} </div> </div> |
現在，替換掉了無序列表，我們使用Bootstrap警告框。同時我們根本不需要改變控制器程式碼！更重要的是，不論日誌何時或者如何更新，檢視也會跟著改變。自動的！漂亮！
雖然我沒有在這裡演示出來，但是資料繫結是雙向的。所以這些日誌資訊同樣可以在檢視中被編輯，就像這樣：
|
1 |
<input ng-model="entry.msg" /> |
是不是更開心了？
不同的模型層
在jQuery中，dom有點像模型。但是在angualrjs中，我們有一個分離的模型層， 而這個模型層可以讓我們用任何方式管理，完全獨立於檢視。這對於上面說的資料繫結很有幫助， 還可以維護關注點分離，並且引入更多的可測試性。其它的答案提到了這點，所以我這裡就不再贅述了。
關注點分離
以上所有的這些把我們帶入了這樣的主題：保持你的關注點分離。你的檢視表現的像記錄什麼會發生（大部分情況）的正式記錄；你的模型表現你的資料；你有一個服務層來執行可重用的任務；你執行dom操作並通過指令擴充套件你的檢視；並且你用控制器來組合這些。這些同樣已經在其它答案中提到，我在這裡唯一還要提出的一個事情就是可測試性，我會在下文的另一節裡專門討論。
依賴注入
依賴注入是讓我們實現關注點分離的方法。如果你是一個伺服器端的開發者（從java到php），你可能對這個概念已經非常熟悉了，但是如果你是一個來自jQuery的客戶端的朋友，那麼你可能會認為這個概念是傻淺挫。但是它可不是：）
從一個更廣的觀點來看， 依賴注入意味著你可以非常自由的宣告元件，然後你可以通過任意其它元件，呼叫一個它的例項，然後授權。
你不需要知道載入順序，或者檔案位置，或者其它類似的東西。這種強大的力量可能不會立刻顯現，但是我這裡會提供一個（通常）的例子：測試。
比如在我們的應用中，需要一個通過REST API，同時也依賴於應用狀態，本地儲存實現了伺服器端儲存的服務。當在我們的控制器上跑測試的時候，我們不希望與伺服器端通訊-畢竟我們在測試控制器。我們能夠僅僅新增一個與我們原始元件同名的mock服務，注入器將確保我們的控制器自動獲取偽造物件–我們的控制器不會也不需要知道它們的區別。
那麼既然提到測試……
4. 保持測試驅動的開發
這個其實是關於架構的第三節的一部分，但是這個主題非常重要，所以我需要將其提出來作為自成體系的部分。
那些你看過，用過，寫過的所有jQuery外掛，它們中有多少有相應的測試包？不是很多吧？ 因為jQuery可不是很遵守這個規矩。但是angualrjs是。
在jQuery中， 測試的唯一方法是用示例頁面來獨立地建立元件，針對該頁面我們的測試可以實施dom操作。於是我們就不得不分離地開發一個元件然後將其整合進我們的應用。多麼不方便啊！
那麼多時間啊，當我們使用jQuery開發時，我們選擇使用迭代開發代替測試驅動的開發。可以誰又能怪我們呢？
但是因為我們有關注點分離，我們能夠在Angular.js裡反覆使用測試驅動開發。舉個例子，我們想要一個超簡單的指令來指示在選單中我們目前的路徑是什麼。我們可以在檢視中這樣宣告我們想獲取的：
|
1 |
<a href="/hello" when-active>Hello</a> |
好了，我們現在可以寫個測試：
|
1 2 3 4 5 6 7 8 9 |
it( 'should add "active" when the route changes', inject(function() { var elm = $compile( '<a href="/hello" when-active>Hello</a>' )( $scope ); $location.path('/not-matching'); expect( elm.hasClass('active') ).toBeFalsey(); $location.path( '/hello' ); expect( elm.hasClass('active') ).toBeTruthy(); })); |
我們執行測試，並確認它是失敗的。那麼我們來寫下我們的指令：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
.directive( 'whenActive', function ( $location ) { return { scope: true, link: function ( scope, element, attrs ) { scope.$on( '$routeChangeSuccess', function () { if ( $location.path() == element.attr( 'href' ) ) { element.addClass( 'active' ); } else { element.removeClass( 'active' ); } }); } }; }); |
現在我們的測試通過了，並且我們的選單按照請求執行。我們的開發是迭代並且測試驅動的，太酷了哦！
5. 從概念上來看，指令不是打包的jQuery
你會經常聽到“只在指令裡做dom操作”。這是必要的。請對它表示出尊重！
但是讓我們談點更深入的。。。
一些指令只是裝飾那些在檢視裡的已有的（想想ngClass），因此有時候就直接進行dom操作，基本上都能搞定。但是如果一個指令像個“widget”並有一個模板，
那它同樣要遵守關注點分離原則。也就是說，這個模板也應該與它在連結和控制器函式裡的實現保持最大的獨立。
Angular.js自帶著一套工具讓這件事變得簡單； 使用ngClass我們能夠動態的更新類；ngBind允許雙向的資料繫結；ngShow和ngHide以程式設計的方式顯示或隱藏一個元素；還有更多–包括我們自己寫的那些。換句話說， 我們可以不用DOM操作來實現所有的酷炫的事兒。 dom操作越少，指令越容易測試，它們也更容易樣式化，在未來它們也更容易改變，並且也變得更加可重用和可分發。
我看到很多Angular.js開發新手將指令當做放置一堆jQuery的地方。換句話說， 他們認為：“既然我不能在控制器裡做dom操縱，那麼我就把這段程式碼放到指令裡”。當然這看上去好多了，但是通常這仍然是錯的。
想一下在第三節裡我們編寫的日誌記錄。即使我們將其放到一個指令裡，我們仍然希望用“anggualjs方式”來做這件事情。這仍然沒有做任何dom操作！在很多情況下dom操作是必須的，但是這種情況其實比你想的少得多！在你在你的應用中到處使用dmo操作之前，問問你自己，這真的是必須的嗎。可能有更好的方法呢。
這裡用一個簡單的例子來展示我們經常會看到的一個模式。我們需要一個切換按鈕。（注意：這個例子有那麼一點人為設計的技巧並且有點囉嗦，但是很多更復雜的情況其實也完全可以根據這個例子的方式來解決。）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
.directive( 'myDirective', function () { return { template: '<a class="btn">Toggle me!</a>', link: function ( scope, element, attrs ) { var on = false; $(element).click( function () { if ( on ) { $(element).removeClass( 'active' ); } else { $(element).addClass( 'active' ); } on = !on; }); } }; }); |
這裡有一些錯誤。第一，jQuery不是必須的。我們這裡做的一切都不需要jQuery！第二， 即使是我們的頁面上已經有jQuery，也沒有理由一定要在這裡使用它；我們可以簡單的使用angular.element，而且就算在一個沒有jQuery的專案中我們的元件仍然可以工作。第三，即使我們假設為了讓這個指令工作，jQuery是必須的，如果jqury被載入，那麼jqLite（angler.element）一定會使用jQuery。所以我們不需要使用$（譯者注：jQuery的一個識別符號號，是jQuery函式的別名）–我們可以使用angular.element。第四， 緊接第三點，jqLite元素不需要被包裹在$裡–傳遞給link函式的element已經是一個jQuery元素！第五， 我上一節已經提過的，為什麼我們要將模板混合進我們的邏輯呢？
這個指令可以更精簡的重寫（即時在更復雜的例子裡也一樣）：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
.directive( 'myDirective', function () { return { scope: true, template: '<a class="btn" ng-class="{active: on}" ng-click="toggle()">Toggle me!</a>', link: function ( scope, element, attrs ) { scope.on = false; scope.toggle = function () { scope.on = !$scope.on; }; } }; }); |
再次強調，模板的那些程式碼都是在模板裡的，所以你或者你的使用者能夠很方便的將其換成一個符合任何需要的樣式，同時邏輯不被改變。這就是重用性-贊！
當然，還有其它很多好處–比如測試 – 這很容易！ 不論什麼在模板中，指令的內部API絕不會被接觸，所以重構就變得容易。你可以在不接觸指令的情況下隨意改變你的模板。並且不論你怎麼變，你的測試仍可以通過。
耶！
所以如果指令不只是一組jQuery風格的函式，那麼它們是什麼呢？指令其實就是html的擴充套件。如果html不能完成你希望它做的一些事情，你就寫一個指令來做，並且當它是html的一部分來使用。
換句話說， 如果Angular.js一下子無法完成手頭的工作，想想看你的團隊是否能用ngClick、ngClass等來搞定它。
總結
別用jQuery。甚至都別引用它。它會阻礙你。當你有個問題已經知道怎麼用jQuery來解決的時候，在你將手伸向$的時候，試試能不能在Angular.js的規範內解決。如果你不知道，就問！
十有八九最佳的方法是不需要jQuery的，而當你選擇用jQuery的時候反而會導致更多的工作呢。