有jQuery背景的我，該如何用AngularJS編程思想？

導讀：本文由機器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標籤來定義一個下拉菜單：

<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中，根據咱們應用的邏輯，能夠用相似下面的語句來激活它。

$('.main-menu').dropdownMenu();

當咱們只是看着視圖的時候，不會馬上看出它的功能。對於小應用而言，這樣是沒問題的。可是對於大型的應用，狀況就一會兒變得使人困惑而且難以維護。

可是在Angular.js中，視圖是基於視圖的功能的正式記錄。咱們的ul是像下面這樣聲明的：

<ul class="main-menu" dropdown-menu>
    ...
</ul>

這二者其實作了一樣的事情，可是在Angular.js的版本中，任何看到這個模板的人都知道將要發生什麼。不論什麼時候，開發團隊裏有任何新的開發人員加入，她能夠一眼看出有一個叫作dropdownMenu的指令做用在視圖上；她根本不須要憑直覺猜想或者研究下代碼才找到正確的答案。視圖自己就告訴咱們將會發生什麼了。清晰多了。

angualrjs的新手常常會問這樣一個問題： 我如何找到某一類全部的連接而且給它們添加一個指令呢？當看到咱們回覆的時候小夥伴都震驚了：壓根別去這樣作。可是勸你不要這樣作的緣由是，這樣作就像是一半jQuery，一半angulrjs，而這真心很糟。這裏的問題是，開發者想在angualrjs的情境中使用jQuery方式。而這絕對不會玩得轉。視圖是正式記錄。超出指令的範圍（這點下文會談論更多），你毫不要去改變DOM。並且指令是應用在視圖中的，目的天然也一目瞭然。

記住：不要先設計再修飾。你必須先進行架構，而後再考慮設計。

數據綁定

這是Angular.js目前最酷的特性之一，而且秒殺我前文提到的各類須要的DOM操做。不須要你本身動手，Angular.js將自動更新你的視圖有木有!

在jQuery裏， 咱們響應事件並更新內容，大概是這個樣子：

$.ajax({
  url: '/myEndpoint.json',
  success: function ( data, status ) {
    $('ul#log').append('<li>Data Received!</li>');
  }
});

視圖則看上去是這樣的：

<ul class="messages" id="log">
</ul>

除了關注點混合的問題，這裏一樣有以前提到的表徵目的的問題。更重要的是，咱們不得不手動引用並更新dom節點。而且若是咱們想要刪除一個日誌，咱們不得再也不次對dom編程操做。咱們怎樣才能拋開dom來測試邏輯呢？還有，若是咱們但願改變展示呢？

 

真是讓人凌亂。。。

可是在Angular.js中，咱們能夠這樣作：

$http( '/myEndpoint.json' ).then( function ( response ) {
    $scope.log.push( { msg: 'Data Received!' } );
});

咱們的視圖看上去是這樣的：

<ul class="messages">
    <li ng-repeat="entry in log">{{ entry.msg }}</li>
</ul>

可是考慮到剛纔提到的問題，咱們的視圖看上去能夠是這樣的：

<div class="messages">
    <div class="alert" ng-repeat="entry in log">
        {{ entry.msg }}
    </div>
</div>

如今，替換掉了無序列表，咱們使用Bootstrap警告框。同時咱們根本不須要改變控制器代碼！更重要的是，不論日誌什麼時候或者如何更新，視圖也會跟着改變。自動的！漂亮！

雖然我沒有在這裏演示出來，可是數據綁定是雙向的。因此這些日誌信息一樣能夠在視圖中被編輯，就像這樣：

<input ng-model="entry.msg" />

是否是更開心了？

不一樣的模型層

在jQuery中，dom有點像模型。可是在angualrjs中，咱們有一個分離的模型層， 而這個模型層可讓咱們用任何方式管理，徹底獨立於視圖。這對於上面說的數據綁定頗有幫助， 還能夠維護關注點分離，而且引入更多的可測試性。其它的答案提到了這點，因此我這裏就再也不贅述了。

關注點分離

以上全部的這些把咱們帶入了這樣的主題：保持你的關注點分離。你的視圖表現的像記錄什麼會發生（大部分狀況）的正式記錄；你的模型表現你的數據；你有一個服務層來執行可重用的任務；你執行dom操做並經過指令擴展你的視圖；而且你用控制器來組合這些。這些一樣已經在其它答案中提到，我在這裏惟一還要提出的一個事情就是可測試性，我會在下文的另外一節裏專門討論。

依賴注入

依賴注入是讓咱們實現關注點分離的方法。若是你是一個服務器端的開發者（從java到php），你可能對這個概念已經很是熟悉了，可是若是你是一個來自jQuery的客戶端的朋友，那麼你可能會認爲這個概念是傻淺挫。可是它可不是：）

從一個更廣的觀點來看， 依賴注入意味着你能夠很是自由的聲明組件，而後你能夠經過任意其它組件，呼叫一個它的實例，而後受權。

你不須要知道載入順序，或者文件位置，或者其它相似的東西。這種強大的力量可能不會馬上顯現，可是我這裏會提供一個（一般）的例子：測試。

好比在咱們的應用中，須要一個經過REST API，同時也依賴於應用狀態，本地存儲實現了服務器端存儲的服務。當在咱們的控制器上跑測試的時候，咱們不但願與服務器端通信-畢竟咱們在測試控制器。咱們可以僅僅添加一個與咱們原始組件同名的mock服務，注入器將確保咱們的控制器自動獲取僞造對象–咱們的控制器不會也不須要知道它們的區別。

那麼既然提到測試……

4. 保持測試驅動的開發

這個實際上是關於架構的第三節的一部分，可是這個主題很是重要，因此我須要將其提出來做爲自成體系的部分。

那些你看過，用過，寫過的全部jQuery插件，它們中有多少有相應的測試包？不是不少吧？ 由於jQuery可不是很遵照這個規矩。可是angualrjs是。

在jQuery中， 測試的惟一方法是用示例頁面來獨立地建立組件，針對該頁面咱們的測試能夠實施dom操做。因而咱們就不得不分離地開發一個組件而後將其集成進咱們的應用。多麼不方便啊！

那麼多時間啊，當咱們使用jQuery開發時，咱們選擇使用迭代開發代替測試驅動的開發。能夠誰又能怪咱們呢？

可是由於咱們有關注點分離，咱們可以在Angular.js裏反覆使用測試驅動開發。舉個例子，咱們想要一個超簡單的指令來指示在菜單中咱們目前的路徑是什麼。咱們能夠在視圖中這樣聲明咱們想獲取的：

<a href="/hello" when-active>Hello</a>

好了，咱們如今能夠寫個測試：

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();
}));

咱們運行測試，並確認它是失敗的。那麼咱們來寫下咱們的指令：

.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操做以前，問問你本身，這真的是必須的嗎。可能有更好的方法呢。

這裏用一個簡單的例子來展現咱們常常會看到的一個模式。咱們須要一個切換按鈕。（注意：這個例子有那麼一點人爲設計的技巧而且有點囉嗦，可是不少更復雜的狀況其實也徹底能夠根據這個例子的方式來解決。）

.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元素！第五， 我上一節已經提過的，爲何咱們要將模板混合進咱們的邏輯呢？

這個指令能夠更精簡的重寫（即時在更復雜的例子裏也同樣）：

.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的時候反而會致使更多的工做呢。