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

這個模式也執(zhí)行了單一職責(zé)原則，規(guī)定了每個類應(yīng)該具有一個單一的職責(zé)，而且它的職責(zé)應(yīng)該封裝與這個類之中，因為模型與集合要處理數(shù)據(jù)，而視圖要處理渲染。
路由中的參數(shù)

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

因此，你的URL結(jié)構(gòu)將會呈現(xiàn)如下：

 





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

 





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

上面的代碼現(xiàn)在轉(zhuǎn)變?yōu)橄旅婢S護性更強的樣子：

 





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

 





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

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

 





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

 





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

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

 





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

 





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

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

 





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

 





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

 





單頁面應(yīng)用中的緩存對象
當(dāng)我們談?wù)搯雾撁鎽?yīng)用時，另一個叫緩存對象模式你將會經(jīng)常用到！下面的例子直截了當(dāng)而且簡單：





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

 





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

 





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

 





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




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