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

作者：jiqihuman 2013-09-04 10:54:39

在jQuery中，你會先設計一個頁面，然后讓它變得動態化。這是因為jQuery是為了擴展而設計的，并在這個前提下變得越來越臃腫。但是在Angular.js中，你必須從一開始就在腦子里掛著架構的弦。

導讀：本文由機器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來測試邏輯呢？還有，如果我們希望改變展現呢？

#p#

真是讓人凌亂。。。

但是在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' );  
                }  
            });  
        }  
    };  
});

現在我們的測試通過了，并且我們的菜單按照請求運行。我們的開發是迭代并且測試驅動的，太酷了哦！

#p#

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