什么是前端路由
路由，引導、指路之意。

譬如我們熟知的路由器，蹦跶在網絡層的數據包轉發(fā)設備，在網絡中也是扮演著指路明燈的角色，肩負著將數據包正確導向目的地址的重任。

前端路由也借用了這個詞，但是承擔的工作全然不同，它是服務于客戶端瀏覽器的指路人。

所謂的前端路由，擁有這樣一種能力：客戶端瀏覽器可以不依賴服務端，根據不同的URL渲染不同的視圖頁面。

前端路由的存在合理性
在Ajax之劍還未亮出，前端仍處于襁褓之中的時候，路由的工作交給了后端。在進行頁面切換的時候，瀏覽器發(fā)送不同的url請求；服務器接收到瀏覽器的請求時，通過解析不同的url去拼接需要的html或者模板，然后將結果返回給瀏覽器端進行渲染。

服務器端路由也是不落俗套的有利亦有弊。它的好處是安全性更高，更嚴格得控制頁面的展現。這在某些場景中是很有用的，譬如下單支付流程，每一步只有在上一步成功執(zhí)行之后才能抵達。這在服務器端可以為每一步流程添加驗證機制，只有驗證通過才返回正確的頁面。那么前端路由不能實現每一步的驗證？自然不是，姑且相信你的代碼可以寫的很嚴謹，保證正常情況下流程不會錯，但是另一個不得不面對的事實是：前端是毫無安全性可言的。用戶可以肆意修改代碼來進入不同的流程，你可能會為此添加不少的處理邏輯。相較之下，當然是后端控制頁面的進入權限更為安全和簡便。

另一方面，后端路由無疑增加了服務器端的負荷，并且需要reload頁面，用戶體驗其實不佳。

這樣，前端路由就有用武之地了。首先，它的出現無疑減輕了服務器端的壓力。特別是對于一個比較復雜的應用來講，或者更確切的說，對于擁有一個復雜路由系統(tǒng)的應用來說，服務器端需要為每一個不同的url執(zhí)行一段處理邏輯在高并發(fā)的情況下實在有點不堪重負；其次，頁面的切換可以不需要刷新整個頁面了，沒有網絡延遲，沒有閃爍刷新，提升了用戶體驗。

前端路由實現方式
既然目標實現，我們需要解決的問題有哪些？我們可以將問題拆的稍微細一點，先制定一個億的小計劃，實現之后再進行下一步：）

• 在頁面不刷新的前提下實現url變化
• 捕捉到url的變化，以便執(zhí)行頁面替換邏輯

如何實現更新url并且頁面不刷新
正如前面所說，前端路由相較于后端路由的一個特點就是頁面在不完全刷新的情況下進行視圖的切換。頁面url變了，但是并沒有重新加載！看上去似乎有點不可思議，其實也沒什么大不了。

試想將瀏覽器地址欄當做一個輸入框，我們需要實現的就是改變輸入框的value但是不觸發(fā)請求頁面的操作，這樣就不會重新加載新頁面。倘若輸入框的值的變化和發(fā)送請求是一個原子操作，我們也就束手無策了。慶幸的是，只有當我們敲擊了回車之后，請求才會被發(fā)送出去（這是顯而易見的吧）。因此這就為我們修改地址欄的值而不觸發(fā)頁面請求刷新創(chuàng)造了條件。BOM是否有提供修改瀏覽器地址欄url而不觸發(fā)請求操作的方法呢？

這里，存在兩種滿足需求的方式。一是利用url中的hash字段；二是使用html5提供的history API。

hash方式
了解http協(xié)議就會知道，url的組成部分有很多，譬如協(xié)議、主機名、資源路徑、查詢字段等等，其中包含一個稱之為片段的部分，以“#”為標識。

例如：http://www.gmail.com/text/#123，123便是url中的hash部分。

打開控制臺，輸入 location.hash，你可以得到當前url的hash部分（如果當前url不存在hash則返回空字符串）。接下來，輸入 location.hash = '123'，會發(fā)現瀏覽器地址欄的url變了，末尾增加了’#123’字段，并且，頁面沒有被重新刷新。很顯然，這很符合我們的要求。

history API
html5引入了一個history對象，包含了一套訪問瀏覽器歷史的api，可以通過window.history訪問到它。

這里我們看上了它的兩個api方法：pushState 和 replaceState。

若上所示，它們接收完全相同的參數，都是對瀏覽器的歷史棧進行操作，將傳遞的url和相關數據壓棧，并將瀏覽器地址欄的url替換成傳入的url且不刷新頁面（正中下懷！）。

By the way，不同的地方是pushState 將指定的url直接壓入歷史記錄棧頂，而 replaceState 是將當前歷史記錄棧頂替換成傳入的數據。

這兩種方式都可以幫我們滿足題設條件。采用哪一種方式除了主觀喜好之外，還得依照客觀事實：低版本的瀏覽器對于history API的兼容性不好，例如遇到了IE8，擺在眼前的道路似乎就別無選擇了。

如何跟蹤url變化
在瀏覽器端，跟蹤表單屬性的變化一般都采用事件監(jiān)聽機制，跟蹤url的變化也不落俗套。

對于hash方式的前端路由，通常可以監(jiān)聽 hashchange 事件，在事件回調中處理相應的頁面視圖展示等邏輯。

此外，html5提供的 popstate 事件也會在url的hash發(fā)生改變時觸發(fā)。也就是說如果可以忽略低版本瀏覽器，我們使用hash方式路由時也可以采用監(jiān)聽這個事件進行回調處理。

那么，如果是采用history API的形式呢？根據MDN的描述：

調用 history.pushState() 或者 history.replaceState() 不會觸發(fā) popstate 事件。popstate 事件只會在瀏覽器某些行為下觸發(fā), 比如點擊后退按鈕（或者在JavaScript中調用 history.back() 方法）。

這也就是說，我們在使用history API改變?yōu)g覽器的url時，仍需要額外的步驟去觸發(fā) popstate 事件，例如調用 history.back() 會 history.forward() 等方法。

從兼容性上來講，前面有提及hash的方式兼容性更好。然而，對于低版本的瀏覽器，例如IE6等等，不支持 hashchange 事件。這個時候我們只能通過 setInterval 設置心跳的方式去模擬 hashchange。

一個簡單實現
這里，給出一個很簡單的實現：

router.js

index.html

index.js

一點總結
應用場景
前端路由大部分的應用場景，就是我們現在熟知的單頁應用SPA。

不存在純前端路由
我們此前所描述的前端路由，建立在已經打開了一個初始頁面基礎之上，然后在這個頁面之內進行頁面替換。然而，我們如何進入這個初始頁面？僅靠前端路由肯定是力所不及。我們至少要向后端發(fā)送一次http請求，接收所需要加載的頁面不是嗎？

所以，我們并不能拋棄后端路由部分。這也意味著，我們需要和后端確認各自的分工，哪些url歸前端解析，哪些歸后臺解析。

關于本文
作者：@陶天然
原文：http://tomasran.space/archives/1bjDjwd2FgzJIsCyshbzag/