Backbone.js的一些使用技巧_javascript類庫

這個模式也執行了單一職責原則，規定了每個類應該具有一個單一的職責，而且它的職責應該封裝與這個類之中，因為模型與集合要處理數據，而視圖要處理渲染。
路由中的參數

最好的演示這個模式工作方式是舉個例子。比如說你需要對搜索頁面進行排序，每個搜索頁面都允許用戶添加兩個不同的過濾類型foo和bar，每個類型代表不同的觀點。

因此，你的URL結構將會呈現如下：

 





現在，所有的路由都用的是同一個試圖和模型，這樣大多數人喜歡用同一個函數search()來實現。然而，你要是檢查過Backbone.js代碼的話，你會發祥它里面沒有排序的參數映射；這些參數只是從左至右依次傳入函數。這樣，為了都能統一使用一個函數，你就要停止創建不同的函數正確的來為search()匹配參數。

 





你也許能想象的到，這個模式可以使路由功能很快膨脹。當我第一次遇到這個問題時，我試圖創建了一些用正則表達式定義的解析函數來“神奇”的去匹配參數，當然這個是可以工作的-但這也是有約束條件的。這樣，我廢棄了這個想法(有時，我仍然可以用Backbone插件來解決)。我進入GitHub中的一個 議題，其中Ashkenas建議應該讓所有的參數都和search函數匹配。

上面的代碼現在轉變為下面維護性更強的樣子：

 





這種模式可以戲劇性的減少路由的過分膨脹。然而，需要注意到它不會服務于不能區別的參數。比如，如果你有兩個作為ID的參數，如模式XXXX-XXXX,你不能區分哪個ID是對哪個參數的回應。
model.fetch() 不會清除你的模型
這通常會將那些Backbone.js的新手給絆倒：model.fetch()并不能丟掉你的模型，而是擴展了你的模型的屬性。因此，如果你的模型具有屬性x,y和z，你獲取到y和z，那么x將仍然是模型中的那個x，只有y和z會被更新。下面的例子將這個概念形象化了。

 





PUTs 需要一個 ID 屬性
這一條也經常將Backbone.js的新手絆倒。要想在調用.save()的時候讓模型發送一個HTTP PUT請求，你的模型需要有一個ID屬性集。記得HTTP PUT謂詞是設計來做更新的吧，所以發送一個PUT請求，你的模型需要有一個ID，這么做是有意義的。在理想的世界里，你的所有模型都具有一個名為ID的完美的ID屬性，但是你從端點接收到的JSON數據可能并不總是具有完美命名的IDs。
因此，如果你需要更新一個模型，請在保存之前確認模型上有ID。Backbone.js 的0.5以及更高版本允許你用id屬性來更新模型的ID屬性名稱，如果你的端點返回的不是名為id的IDs的話。

如果困頓于使用的是版本低于0.5的Backbone.js，我建議你修改你的模型或集合的parse函數，以便將你期望的ID屬性映射到屬性ID。這里有一個快速上手的例子，說明了你應怎樣修改parse函數來做到這一點。我們假設你有一個cars的集合，它的IDs是carID。

 





頁面加載時創建模型數據
有時你會發現你的模型或者集合需要在頁面加載時被初始化賦值。許多關于Backbone.js模式的文章，例如Rico Sta Cruz的 “Backbone 模式” 和 Katz的 “ 避免常見的Backbone.js陷阱” ，討論了這種模式。這種模式實現很容易，只需在頁面中內聯一段腳本，通過你選擇的服務端語言，將單個模型屬性或者JSON形式的數據呈現出來。例如，在Rails語言中，我采用下面方法之一：

 





應用這種模式可以通過“立即的”渲染頁面，改善你的搜索引擎排名，而且它也可以通過限制應用初始化HTTP請求的方式，大大縮短你的應用啟動與運行所需要的時間。
處理失敗的模型屬性驗證
很多時候，你會想知道是哪個模型屬性驗證失敗了。例如，如果你有一個極其復雜的表單，你或許想知道哪個模型屬性驗證失敗，這樣你就可以將這個屬性對應的輸入字段高亮顯示。不幸的是，提醒視圖到底是哪個模型屬性驗證失敗并沒有直接集成于Backbone.js，但是你可以用一些不同的模式去處理這個問題。

返回一個錯誤對象
一個給視圖提醒哪個模型屬性驗證失敗的模式是，返回一個對象，其中包含某種標志，它詳細的記錄了哪個屬性驗證為失敗，就像下面這樣：

 





這個模式的優點在于，你是在一個地方處理所有不合法的消息。缺點在于，如果你以不同的方式處理不合法的屬性的話，你的invalid方法可能會成為一個很大的switch或者if語句。
廣播自定義Error事件
我的一個朋友，Derick Bailey，推薦了一個可替代模式，就是為每個模型屬性觸發自定義的errors事件。這將允許你的視圖能夠針對單獨的屬性綁定到特定的error事件：

 





這個模式的優點在于，你的視圖明確的綁定到它們所綁定到的error類型，而且如果你對每一種屬性error有特定的指令的話，它可以清理你的視圖部分代碼，使之更易于維護。這個模式的一個不好的地方在于，如果在你處理不同的屬性error時并沒有太多的不同的話，你的視圖可能會變得極為膨脹。
這兩種模式都有其利弊，你應該考慮清楚哪個模式對你的應用案例是最優的。如果你按照同樣的方式處理所有失敗的驗證，那么第一個方法可能是最好的；如果你對每個模型屬性有特定的UI變化，那么后一種方法更好。
HTTP狀態代碼200所觸發的錯誤

如果你的瀏覽器端模型或者集合收到了無效的JSON，盡管HTTP的狀態代碼是200，但瀏覽器端依然會觸發一個“錯誤”事件。這種事件常發生于本地模擬JSON數據造成的。那么，一個好的方法就是讀取經過 JSON 驗證器驗證了的模擬JSON數據文件。或者從你的IDE獲得相應的 插件來及時獲取格式錯誤的JSON信息。
創建一個一般性錯誤顯示模式
創建一個常見錯誤顯示代碼可以節省你的時間以及創建一個統一的模式來處理、可視化錯誤信息，而且它可以增加開發者的經驗。我之前開發的每一個Backbone.js應用中我都會創建一個可以處理alert的視圖：

 





上面的代碼首先會檢查是否已在視圖代碼中創建了指定視圖in-page-alert div。如果沒有,則接著查看一般性的在其它地方聲明的body-alert div。這樣可以讓你發送具有一致性的錯誤信息以及當你忘記指定一個in-page-alert div時提供有用且可靠的信息。如下面的模式簡化了讓你怎樣在你的試圖中處理錯誤信息：

 





單頁面應用中更新瀏覽器頁面標題
這是一個比任何東西都重要的可用性問題。如果你正在開發一個單頁面應用程序，謹記更新每個頁面的標題。我寫過一個的插件（Backbone.js Router Title Helper）來擴展 backbone.js router 的功能。它通過一個 Map 對象來控制路由，鍵來代表路由函數的名字，值則映射到頁面的標題。

 





單頁面應用中的緩存對象
當我們談論單頁面應用時，另一個叫緩存對象模式你將會經常用到！下面的例子直截了當而且簡單：





這個模式可以加速你得應用，因為你不用重復初始化你得Backbone.js對象。然而，它會過多的消耗內存；所以，緩存對象就要在整個應用中使用。如果以前你用過Backbone.js開發過應用，也許你會問你自己，“ 我要重取數據該怎么做？”你可以每次在如下路徑中觸發后重取數據：

 





當你的應用從端點(如，一個收件箱)必須檢索最新數據時上面的模式就可以工作。當然，如果你要拿的數據時憑借應用的某個狀態(假設這個狀態是通過URL和參數來決定的)，甚至是在用戶上一個頁面應用的狀態沒有改變， 你可以重取數據。一個好的解決方案去重拿數據時當應用(參數)發生變化時：

 





JSDoc函數和Backbone.js類
我是文檔注釋和JSDoc的超級粉絲。我用JSDoc對所有的Backbone類添加了文檔注釋：

 





如果你對Backbone類進行如上添加文檔注釋，這樣你可以給所有類和函數 添加參數、返回類型以及描述文檔注釋了。確保保持初始化函數作為一個聲明的函數，這樣可以幫助我們生成JSDoc。如果你想看看JSDoc的例子工程，那就在 HomeAway Calendar Widget下載例子。同時這里也有個 Grunt.js插件， grunt-jsdoc-plugin，這個也可以作為你構建文檔注釋時的一部分。
聯系測試驅動的開發模式
我認為如果你用Backbone.js，你應該在開發模型和集合時遵循測試驅動開發(TDD)。我第一次用Jasmine.js創建模型和集合時遵循TDD進行單元測試，但失敗了。一旦寫下單元測試并且失敗，我會對整個模型和集合進行重寫。
通過這一點，我的所有Jasmine測試都通過了，而且我有信心我的模型和集合會和我期望的一樣工作。自從我遵循TDD，我的視圖層非常容易寫而且非常簡單。當你開始用TDD時，你得速度當然會很慢；但是一但你得腦海里一直想著TDD，你的編程效率和質量會神奇般的提高。 




聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com