前端路由的簡單實現

剛完成一個新年專題活動的需求，分為pc端和wap端。pc端下多個彈窗在wap端下全部設計成多個單張頁面呈現

為了更好的用戶體驗首選SPA單頁面實現。

SPA單頁面的優缺點

優點：

• 用戶體驗好，內容的改變不需要重新載入整個頁面，避免了不必要的跳轉和重複渲染。

• 基於不需要重新載入整個頁面，減少了向伺服器端的請求，即節約了成本又對伺服器的壓力大大減小。

缺點：

• 不利於seo搜索引擎優化

• 初次載入頁面更耗時

市面上有大量的SPA框架，如React，Vue等，它們有許多相似之處，都有：

• 使用 Virtual DOM（虛擬DOM）

• 提供了響應式(Reactive) 和組件化(Composable) 的視圖組件。

• 將注意力集中保持在核心庫，而將其他功能如路由和全局狀態管理交給相關的庫。

對於一個專題活動又不是一個獨立的中大型項目使用這些框架有點重了，不以項目大小、項目需求為導向的技術選型就是耍流氓行為，在這個專題活動中我只需要一個簡單的路由。

前端路由主要由兩種方式實現：

• location.hash和hashchange事件

• H5 history Api中的history.pushState和popState事件(不在本文討論範圍,請自行搜索)

hash+hashchange實現

hash屬性是一個可讀可寫的字元串，該字元串是 URL 的錨部分（從 # 號開始的部分）。

修改hash值從

改成

瀏覽器不會重新向伺服器請求index.html，就是說不會重新載入整個頁面。這時只要通過hashchange事件監聽location.hash的變化，做相應的處理即可。

• 設置a標籤href 屬性為 "#location1"，點擊時就可以在當前url的後面增加上"#location1"，同時觸發hashchange,再回調函數中進行處理。

• 直接在js中對location.hash = "#location1"賦值，此時url也會跟著改變，同時觸發hashchange事件。

前端路由的簡單實現，代碼如下僅供參考：

hash這種方式的好處是瀏覽器兼容性好，但也有一個缺點就是#的存在，讓一些人看了覺得不是很舒服，所以H5給history新增了一些api，代碼簡單，url可以隨意指定，如果是純相對路徑需要與伺服器端相配合。

代碼不重要，重要的是思路。。。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！