簡述AngularJS相關的一些編程思想

 

　　這篇文章主要介紹了AngularJS相關的一些編程思想,AngularJS是一款熱門的JavaScript庫,推薦!需要的朋友可以參考下

　　在過去的幾個月裡，我一直遨游於Angular的世界。如今回想起來，很難想象在沒有類似於Angular.js, Backbone.js以及其伙伴Underscore.js這些數據綁定框架下我每天如何去編寫一個大型前端應用。我不敢相信我已經用它們完成了那件工作。

　　可能我有點小偏見，但考慮到我一直在做的應用是在浏覽器中實現Photoshop類型的編輯器，它呈現相同的數據有幾種完全不一樣的方式。

　　圖層以圖形化的形式呈現，占據了屏幕的大部份。它們列於一個面板內，你可以刪除它們。

　　當你選中一個圖層時，它的邊緣會被虛線包圍，同時會高亮顯示於列表中。

　　類似地，圖層在面板中的尺寸和它們的大小這些屬性取決於畫布。

　　我上面提到過的面板是可以拖拽，折疊，關閉的。

　　如果不是一個像Augular的框架，這一種類的互動、數據連接和視圖同步很容易變成一個持續的噩夢。有能力修正一個地方的模型和用Augular修正所有相關的視圖聽起來幾乎像在騙人。添加、消除或者改動一個層次只是一個改變對象的問題。層次，x+=10，完成。並沒有地方需要手動作廢視圖、手工地修改在DOM的層次中的每一個實例，甚至是因為這個問題而去與DOM互動。

　　Augular使我們可以去到我們從未想過的地方，像設置一串使我們能夠在現有的環境下做出申請的鍵盤捷徑。舉個例子，文件編輯捷徑(像?B：用於切換黑體文本)只是使我們能夠編輯一個文件層面。

　　同樣地，我們為這些快捷鍵附加了一個描述(通過一個我們創建的服務進行注冊)，然後我們可以顯示一個快捷鍵的列表，同時還有它們的描述，在一個便利條上。此外，我們寫了一個指令使得我們可以將單獨的DOM元素與它們的快捷鍵綁定在一起，當你的鼠標在元素上停留一會，會出現一個提示，讓你知道此時可用的快捷鍵。

　　Angular可以使我們做到我們做夢也想不到的事情。

　　老實說，這就好像我們已經不是在編寫一個web應用。web只是媒介。當我們增進了我們對Angular的理解後，代碼變得更加模塊化，更加獨立，並且更加連接交互。它很自然地變得更加Angular了。

　　然後通過Augular，我的意思是在Augular背後的那些高度互動的豐富的應用開發哲學。javascript，一個讓我們能夠開發那些一段時間前我們還覺得不可能的一部分軟件的相似的東西。

　　我們甚至有能力去開發一個成熟的用於修改DOM變成歷史中現在選中的點的歷史控制板，並讓它工作得很好。至少可以這麼說，當你興奮的返回歷史控制板查看那些與Augular能力相關的數據在你的視圖工作中完美的更新每一個微小的細節。

　　那並不總是容易的，基本代碼總是變成一場無可控制的混亂。

　　的確，在過去幾周裡我們一直在更新並且將我們的前端整個架構重寫。在我們開始重新編寫以前，看一下自從0.10.6以來，將Angular更新得有優勢的過程。如果看了變更日志，你就知道這是一個相當長的過程。

　　在這個重構的過程裡，我們從以錯誤的方法對待Angular，轉變為以Angular的方式對待Angular。

　　在我們的案例中，錯誤的方法包含了許多的問題，我們不得不在此時，在使我們的代碼基礎到達可愛狀態之前，解決它們。

　　在全局作用域聲明控制器(Controllers)

 

　　這是一個 Angular 初學者容易做的例子。如果你熟悉 Angular，你也會熟悉這種模式。

? 1 2 3 4 5 6 7 8 9 10 11 // winds up on window.LoginCtrl ... var LoginCtrl = function ($scope, dep1, dep2) { // scope defaults };   LoginCtrl.prototype.resetPassword = function () { // reset password button click handler };   // more on this one later LoginCtrl.$inject = ['$scope', dep1', 'dep2'];

        這段代碼沒有包含在閉包中，或者說，所有的聲明都在根作用域，全局的 window 對象上，混蛋啊。用正宗的 Angular 方式來寫的話是使用它提供的模塊 api ( module API)。但是如你所見，即使是文檔和建議步驟任然過時地建議你使用全局作用域：

        這樣做，極棒的事情將出現。

? 1 2 3 4 // A Controller for your app var XmplController = function($scope, greeter, user) { $scope.greeting = greeter.greet(user.name); }

       -- Angular.js文檔

         使用模塊(modules)允許我們以下面的方式重寫控制器(controllers)：

? 1 2 3 4 5 6 7 8 9 10 11 12 angular.module('myApp').controller('loginCtrl', [ '$scope', 'dep1', 'dep2', function ($scope, dep1, dep2) { 'use strict';   // scope defaults   $scope.resetPassword = function () { // reset password button click handler }; } ]);

 

　　我發現使用 Angular 控制器的漂亮做法是你必須在所有地方使用控制器方法(controller function)，因為你需要控器的依賴注入，而且控制器提供了新的作用域，綁定我們從需求到封裝我們所有的腳本文件成為自調用函數表達式( self-invoking function expressions)，像這樣 (function(){})()。

　　依賴$injection

　　在最早的例子中你可能已經注意到了, 依賴是使用$inject注入的. 另一方面，大部份的模塊API, 允許你傳入一個函數作為參數, 或者一個包含了依賴的數組作為參數, 其後面跟著一個依賴於這些依賴的函數. 這是在Angular中我不喜歡的一點 , 但這應該是它文檔的過錯. 在文檔中的大部份例子認為你並不需要一個數組形式的參數; 但現實是，你是需要的。 如果你在使用一個壓縮器壓縮你的代碼之前, 沒有運行ngmin , 事情將會變得糟糕.

　　由於你沒有使用數組格式['$scope',...]明確聲明你的依賴包，你看上去簡潔的方法參數將會被縮略成類似於b,c,d,e的樣子，有效地扼殺了Angular的依賴注入能力。我認為他們構建框架的思路存在了重大的失誤，這與我在非常不喜歡 Require.js 和他們麻煩的 AMD 模塊最後的推論是相似的。

　　如果他不能在產品中使用，它還有什麼用?

　　我的這種態度是因為你在產品中所使用的框架裡，有一部分代碼是已經寫死了的。這對於開發中經常用到、產品中偶爾用到的實用工具，諸如控制台和錯誤報告，是很好的。如果語法上的甜頭(可讀性)只用在開發中，就會變得沒有任何意義。

　　這些破事讓我很憤怒, 現在發洩完了. 談談$符吧...

　　減少 jQuery擴散

　　深入的講, 這個應用是 "類Angular程序", 也就是說它只是包裹於Angular之中, 大多數DOM 交互是經由jQuery處理的, 這給Angular帶來相當多的爭論。

　　如果今天我要從頭開始寫一款Angular.js應用，我不會立即包含進jQuery。我會強迫自己使用 angular.element 來代替。

　　如果jQuery存在的話，angular.element這個API將包裝它，同時它給Angular團隊實現 jQuery的API提供了可以替代的選擇，名為jqLite。這並不是說 jQuery不好，或者說我們需要另一個某種實現，來映射它們的API。只是因為使用jQuery顯得不是那麼有Angular的思想。

 

　　讓我們來看一個具體的,愚蠢的,例子。在controller被聲明的地方，它使用jQuery來做元素之上的類操作。

? 1 2 3 4 5 6 7 8 9 div.foo(ng-controller='fooCtrl')   angular.module('foo').controller('fooCtrl', function ($scope) { $('.fo