摘要:由于這種通信方式不需要頁面的刷新動作,因而無論與后臺發(fā)生了多少次通信,瀏覽器的會一直保持在初始地址不變。前端路由的值通常應(yīng)用在單頁面應(yīng)用中。
后端路由
* path(路由分發(fā)) 針對不同的路由對應(yīng)不同的回調(diào)函數(shù)處理(req, res, next) * req;獲取請求參數(shù) * res:返回請求數(shù)據(jù) * next: 調(diào)用后續(xù)的回調(diào)函數(shù)前端路由
* 路由是根據(jù)不同的url去請求不同的頁面內(nèi)容 * 前端路由就是把不同路由對應(yīng)不同的內(nèi)容或頁面的任務(wù)交給前端來做,之前是通過服務(wù)端根據(jù)url不同返回不同的頁面來實現(xiàn)。 * 利用H5的history.pushState?和?history.replaceState?,這兩個history新增的api,為前端操控瀏覽器歷史棧提供了可能性 * 這兩個Api都會操作瀏覽器的歷史棧,而不會引起頁面的刷新。 * 不同的是,pushState會增加一條新的歷史記錄,而replaceState則會替換當前的歷史記錄。 應(yīng)用:單頁面應(yīng)用 優(yōu)點和缺點: * 優(yōu)點: 用戶體驗好,不需要每次向服務(wù)器發(fā)送請求請求頁面數(shù)據(jù),響應(yīng)快 * 缺點:使用瀏覽器的前進,后退鍵的時候會重新發(fā)送請求,沒有合理地利用緩存,hash值得由來
歷史: 1、基于Ajax 的 Web 應(yīng)用最為明顯的特征在于使用了瀏覽器內(nèi)部原生支持的 XMLHttpRequest對象與后臺服務(wù)器進行數(shù)據(jù)通。 2、由于這種通信方式不需要頁面的刷新動作,因而無論與后臺發(fā)生了多少次通信,瀏覽器的 URL 會一直保持在初始地址不變。 3、這隨之而來的一個問題便是不斷變化的頁面狀態(tài)信息無法記錄到瀏覽器的歷史記錄堆棧中,從而使得用戶無法通過瀏覽器的前進 / 后退按鈕在不同狀態(tài)頁面間進行切換。解決思路:
瀏覽器能夠支持在用戶訪問過的頁面間進行前進 / 后退的操作,依賴于內(nèi)部維持的 history 對象。 出于安全性的考慮,瀏覽器并不允許 JavaScript 腳本對該對象進行增刪改之類寫操作, 而只是可以通過 history. back/forward() 等方法進行訪問。既然在頁面狀態(tài)發(fā)生變化時, 無法通過腳本直接去影響瀏覽器的歷史信息,那么只有通過 URL 的變化來觸發(fā)瀏覽器增加一條新的歷史記錄。 這也就是說需要將 Ajax 應(yīng)用的不同頁面狀態(tài)與 URL 進行一種一對一的映射,并且能夠在回退或前進到某一 URL 之時, 應(yīng)用本身能夠在頁面無刷新的情況下跳轉(zhuǎn)到正確的頁面狀態(tài)。如何對 Ajax 應(yīng)用的初始 URL 進行改變, 而同時這種變化的切換又不會引起頁面的重新加載呢?答案只有一個,那就是借助用于頁面內(nèi)資源片段定位目的 的“片段標識符”(fragment identifier),即 URL 中“#”符號后的字符串(hash string)。當瀏覽器向 服務(wù)器端請求資源時,片段標識符并不會連同 base URL 一同發(fā)往服務(wù)器端,而只是在得到服務(wù)器返回的結(jié)果 之后幫助瀏覽器快速定位到被相應(yīng)的錨點(anchor)所標識的資源片段,即使無法找個對應(yīng)的錨點,瀏覽器也并 不會報錯。正是基于瀏覽器的這一特性,構(gòu)建片段標識符與頁面狀態(tài)之間的映射關(guān)系成為了解決此類問題的基礎(chǔ)。
hash值
將任意長度的二進制字符串通過一定的算法映射成一個固定長度的較小二進制字符串,這個字符串就是對應(yīng)的hash值,主要特點就是唯一的,不可逆的。
前端路由的hash值(#)----->angular
hash通常應(yīng)用在spa單頁面應(yīng)用中。因為通過不同的hash值映射的url來是的瀏覽器添加一條不同的url歷史記錄。
通過瀏覽器的pushstate、replaceState來操作,請求不同的瀏覽器記錄達到請求不同的頁面的效果
H5中提供的兩個操作hash值得API來操作hash值
window.location.hash讀取#值
window.onhashchange = func 監(jiān)聽hash改變
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://m.hztianpu.com/yun/84421.html
摘要:所以單頁應(yīng)用的部署,需要將所有的頁面請求都返回,瀏覽器下載了后會自動解析并導航到對應(yīng)頁面??偨Y(jié)單頁應(yīng)用與以前的常規(guī)多頁面應(yīng)用還是有區(qū)別的,開發(fā)過程與后端解耦了,同時會出現(xiàn)跨域鑒權(quán)以及應(yīng)用部署的問題。 本文同步發(fā)布于我的個人博客上 - 單頁應(yīng)用的部署方案 本文主要簡單講一下單頁應(yīng)用的開發(fā)及部署方法,默認你懂一些服務(wù)端知識及nginx知識,如果有任何可以在下方評論留言。 單頁應(yīng)用 SPA(...
摘要:解決思路服務(wù)器端渲染服務(wù)器端和前端公用同一個應(yīng)用,然后通過構(gòu)建工具及配置,確定哪些組件需要再服務(wù)器端渲染,那些組件需要再客戶端渲染。服務(wù)器端渲染,由框架與構(gòu)建工具配合,并依據(jù)一定的項目結(jié)構(gòu)和編碼方式,共同運行。 分離 為什么需要 前后端分離、web服務(wù)器與static服務(wù)器分離: 前端與后端耦合 (需求) 自動化、工程化的構(gòu)建前端的代碼 (基礎(chǔ)條件) 模塊化、組件化,項目共享代碼 (...
摘要:所以,這次就來聊聊組件的服務(wù)器端渲染。這種模式下,后端只提供接口,傳統(tǒng)的服務(wù)器端路由模板渲染則都有層接管。這樣,前端開發(fā)人員可以自由的決定哪些組件需要在服務(wù)器端渲染,哪些組件可以放在客戶端渲染,前后端完全解耦,但又保留了服務(wù)器端渲染的功能。 細說 Vue 組件的服務(wù)器端渲染 聲明:需要讀者對 NodeJs、Vue 服務(wù)器端渲染有一定的了解 現(xiàn)在,前后端分離與客戶端渲染已經(jīng)成為前端開發(fā)的...
閱讀 1603·2021-11-25 09:43
閱讀 4160·2021-11-15 11:37
閱讀 3264·2021-08-17 10:13
閱讀 3572·2019-08-30 14:16
閱讀 3603·2019-08-26 18:37
閱讀 2547·2019-08-26 11:56
閱讀 1214·2019-08-26 10:42
閱讀 701·2019-08-26 10:39