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

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

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

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

 





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

 





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

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

 





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

 





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

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

 





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

 





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

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

 





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

 





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

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

 





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

 





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

 





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





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

 





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

 





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

 





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




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