什么是前端路由
所謂的前端路由,擁有這樣一種能力:客戶端瀏覽器可以不依賴服務端,根據不同的URL渲染不同的視圖頁面。
前端路由的存在合理性
在Ajax之劍還未亮出,前端仍處于襁褓之中的時候,路由的工作交給了后端。在進行頁面切換的時候,瀏覽器發送不同的url
請求;服務器接收到瀏覽器的請求時,通過解析不同的url
去拼接需要的html
或者模板,然后將結果返回給瀏覽器端進行渲染。
服務器端路由也是不落俗套的有利亦有弊。它的好處是安全性更高,更嚴格得控制頁面的展現。這在某些場景中是很有用的,譬如下單支付流程,每一步只有在上一步成功執行之后才能抵達。這在服務器端可以為每一步流程添加驗證機制,只有驗證通過才返回正確的頁面。那么前端路由不能實現每一步的驗證?自然不是,姑且相信你的代碼可以寫的很嚴謹,保證正常情況下流程不會錯,但是另一個不得不面對的事實是:前端是毫無安全性可言的。用戶可以肆意修改代碼來進入不同的流程,你可能會為此添加不少的處理邏輯。相較之下,當然是后端控制頁面的進入權限更為安全和簡便。
另一方面,后端路由無疑增加了服務器端的負荷,并且需要reload
頁面,用戶體驗其實不佳。
這樣,前端路由就有用武之地了。首先,它的出現無疑減輕了服務器端的壓力。特別是對于一個比較復雜的應用來講,或者更確切的說,對于擁有一個復雜路由系統的應用來說,服務器端需要為每一個不同的url執行一段處理邏輯在高并發的情況下實在有點不堪重負;其次,頁面的切換可以不需要刷新整個頁面了,沒有網絡延遲,沒有閃爍刷新,提升了用戶體驗。
前端路由實現方式
既然目標實現,我們需要解決的問題有哪些?我們可以將問題拆的稍微細一點,先制定一個億的小計劃,實現之后再進行下一步:)
在頁面不刷新的前提下實現url
變化
捕捉到url
的變化,以便執行頁面替換邏輯
如何實現更新url
并且頁面不刷新
正如前面所說,前端路由相較于后端路由的一個特點就是頁面在不完全刷新的情況下進行視圖的切換。頁面url
變了,但是并沒有重新加載!看上去似乎有點不可思議,其實也沒什么大不了。
試想將瀏覽器地址欄當做一個輸入框,我們需要實現的就是改變輸入框的value
但是不觸發請求頁面的操作,這樣就不會重新加載新頁面。倘若輸入框的值的變化和發送請求是一個原子操作,我們也就束手無策了。慶幸的是,只有當我們敲擊了回車之后,請求才會被發送出去(這是顯而易見的吧)。因此這就為我們修改地址欄的值而不觸發頁面請求刷新創造了條件。BOM是否有提供修改瀏覽器地址欄url
而不觸發請求操作的方法呢?
這里,存在兩種滿足需求的方式。一是利用url
中的hash
字段;二是使用HTML5提供的history API。
hash
方式
了解http
協議就會知道,url
的組成部分有很多,譬如協議、主機名、資源路徑、查詢字段等等,其中包含一個稱之為片段的部分,以#
為標識。
例如: http://www.gmail.com/text/#123
,123
便是url
中的hash
部分。
打開控制臺,輸入 location.hash
,你可以得到當前url
的hash
部分(如果當前url
不存在hash
則返回空字符串)。接下來,輸入 location.hash = '123'
,會發現瀏覽器地址欄的url
變了,末尾增加了#123
字段,并且,頁面沒有被重新刷新。很顯然,這很符合我們的要求。
history API
HTML5引入了一個history
對象,包含了一套訪問瀏覽器歷史的API,可以通過window.history
訪問到它。
這里我們看上了它的兩個API方法:pushState
和 replaceState
。
history.replaceState(dataObj, title, url);
history.pushState(dataObj, title, url);
若上所示,它們接收完全相同的參數,都是對瀏覽器的歷史棧進行操作,將傳遞的url和相關數據壓棧,并將瀏覽器地址欄的url
替換成傳入的url
且不刷新頁面(正中下懷!)。
By the way,不同的地方是pushState
將指定的url
直接壓入歷史記錄棧頂,而 replaceState
是將當前歷史記錄棧頂替換成傳入的數據。
這兩種方式都可以幫我們滿足題設條件。采用哪一種方式除了主觀喜好之外,還得依照客觀事實:低版本的瀏覽器對于history API的兼容性不好,例如遇到了IE8,擺在眼前的道路似乎就別無選擇了。
如何跟蹤url
變化
在瀏覽器端,跟蹤表單屬性的變化一般都采用事件監聽機制,跟蹤url
的變化也不落俗套。
對于hash
方式的前端路由,通�?梢员O聽 hashchange
事件,在事件回調中處理相應的頁面視圖展示等邏輯。
此外,HTML5提供的 popstate
事件也會在url
的hash
發生改變時觸發。也就是說如果可以忽略低版本瀏覽器,我們使用hash
方式路由時也可以采用監聽這個事件進行回調處理。
那么,如果是采用history API的形式呢?根據MDN的描述:
調用 history.pushState()
或者 history.replaceState()
不會觸發 popstate
事件。popstate
事件只會在瀏覽器某些行為下觸發, 比如點擊后退按鈕(或者在JavaScript中調用 history.back()
方法)。
這也就是說,我們在使用history API改變瀏覽器的url
時,仍需要額外的步驟去觸發 popstate
事件,例如調用 history.back()
會 history.forward()
等方法。
從兼容性上來講,前面有提及hash
的方式兼容性更好。然而,對于低版本的瀏覽器,例如IE6等等,不支持 hashchange
事件。這個時候我們只能通過 setInterval
設置心跳的方式去模擬 hashchange
。
var oldHash = location.hash;var oldURL = location.href;
setInterval(function() { var newHash = location.hash; var newURL = location.href; if (newHash !== oldHash && typeof window.onhashchange === 'function') { // 執行onhashchange回調
window.onhashchange({ 'type': 'hashchange', 'oldURL': oldURL, 'newURL': newURL
});
oldHash = newHash;
oldURL = newURL;
}
}, 100);
一個簡單實現
這里,給出一個很簡單的實現:
router.js
function FrontRouter() { this.routes = {};
window.addEventListener('load', this.resolve.bind(this), false);
window.addEventListener('hashchange', this.resolve.bind(this), false);
}
FrontRouter.prototype.route = function(path, callback) { this.routes[path] = callback function() {};
};
FrontRouter.prototype.resolve = function() { this.curHash = location.hash.slice(1) '/'; typeof this.routes[this.curHash] === 'function' && this.routes[this.curHash]();
};
index.html
<ul> <li><a href='#blue'></a></li> <li><a href='#yellow'></a></li> <li><a href='#red'></a></li></ul>
index.js
var router = new FrontRouter();
router.route('blue', function() {
document.body.style.backgroundColor = 'blue';
});
router.route('yellow', function() {
document.body.style.backgroundColor = 'yellow';
});
router.route('red', function() {
document.body.style.backgroundColor = 'red';
});
一點總結
應用場景
前端路由大部分的應用場景,就是我們現在熟知的單頁應用SPA。
不存在純前端路由
我們此前所描述的前端路由,建立在已經打開了一個初始頁面基礎之上,然后在這個頁面之內進行頁面替換。然而,我們如何進入這個初始頁面?僅靠前端路由肯定是力所不及。我們至少要向后端發送一次http請求,接收所需要加載的頁面不是嗎?
所以,我們并不能拋棄后端路由部分。這也意味著,我們需要和后端確認各自的分工,哪些url歸前端解析,哪些歸后臺解析。