富應用中 URL 管理以及 Javascript 測試

URL 存在的意義在於使用者能夠使用一段字符串就能夠找到對應的資源。富應用中的內容改變都是經過 Javascript 去改變文檔內容，某種角度上來講整個網站其實只須要一個 URL。若是真的使用同一個URL的話，用戶就沒法快速的經過特定字符串進入他想到達到資源。就像搜索引擎的表單都是 GET 而不是 POST，你能夠把你搜索結果的連接發給你的朋友，而後他們也能夠看到相同的內容。因而必須容許 URL 變化。

URL 變化卻不會讓網頁重新載入只有兩種方法。一個是使用錨連接，即 http://url/#path 的方式實現。另外一種就是須要瀏覽器支持的 history.pushState ，後者 github 有使用，Pajax 方案也是使用了這種方法。因爲是寫的初版，目前只實現了錨連接的實現。

相關代碼傳送門：https://github.com/HaiyiYun/VintJS/blob/master/src/location.js

因爲 URL 改變後瀏覽器沒有觸發新的請求，就意味着你須要經過 Javascript 去知道 URL 發生了變化。HTML5 的規範中同時規定了onhashchange 的方法，老式的瀏覽器和 IE 的 documentMode 下面都不支持，因而就須要使用 setInterval 方法來不斷的讀取當前 url ，若是 url 發生了變化就要觸發相應的事件。以前的事件模型在這裏又派上了用途。直接 this.trigger('urlChange') 便完成了這裏的工做，而不須要去考慮路由的代碼或者其餘地方的代碼。

此時還須要的工做就是去解析新的 URL ，先獲取當前的絕對地址，而後去解析。具體參考 __checkUrl 的源碼。分紅當前的 path ，這個會影響當前使用的路由，還有就是 search 的對象。這一塊的代碼是在閱讀了 Angularjs 的基礎上完成的，同時也引用了 Angularjs 的 hash_prefix 設置。谷歌開發文檔中有提到 Ajax Url 的規則，傳送門：https://developers.google.com/webmasters/ajax-crawling/docs/getting-started?hl=zh-CN ，#! 的規則是比較友好的作法，因此預留了這個設置。

完成解析工做後要作的就是去試着改變 URL。直接改變 URL，其中還包括 location.herf = 'xxx' 和 location.replace('xxx') 兩種方式的區別。一種會在瀏覽器的歷史記錄裏面留下痕跡，一種不會。而後須要改變 path ，改變 search 的對應的方法，還有就是獲取當前 url 、 path 、 search 的方法。

這些都完成以後， URL 相關的功能基本上就告一段落。接下來要作的就是路由，將當前的 path 解析至對應的路由上面去並去渲染頁面。

---

華麗麗的分隔符後開始說說 javascript 的測試。

作程序的人大多瞭解測試。寫完一個函數後就去測試一下，看看寫出來的代碼是否是可以達到本身預期的目標。瀏覽器的 javascript 除了要驗證函數的輸入是否覆蓋全面、結果是否等於預期，還須要防止本身的代碼在一些特定的瀏覽器上面存在bug。傳統的測試方法就是在完成後手動去觸發事件，而後手動輸入來檢測是否獲得預期的效果。在接觸具體的測試框架前，我本身的作法經常是在代碼裏面寫一些測試的代碼，而後輸出檢測是否和預期相同。這種的問題就是若是須要檢驗多種瀏覽器的話，工做比較累贅。

引入了測試框架後工做簡單了不少。例如 Qunit，jasmine， 我如今用的是 jasmine ，傳送門：http://pivotal.github.io/jasmine/ 。寫完一個方法，而後寫一些簡單的測試用例，在全部瀏覽器上面容許就能夠知道結果。而無需本身去手動觸發或者是寫代碼輸出而後去比照。

---

前篇傳送門：

給本身挖個坑，開始去開發javascript富應用框架

從 BackboneJS 的源碼開始說事件模型