前端路由與后端路由的思考

tuomao 發布于2019-08-20 18:22 / 1391人閱讀

摘要：由于這種通信方式不需要頁面的刷新動作，因而無論與后臺發生了多少次通信，瀏覽器的會一直保持在初始地址不變。前端路由的值通常應用在單頁面應用中。

后端路由

* path（路由分發）
    針對不同的路由對應不同的回調函數處理(req, res, next)
    * req;獲取請求參數
    * res：返回請求數據
    * next: 調用后續的回調函數

前端路由

* 路由是根據不同的url去請求不同的頁面內容
* 前端路由就是把不同路由對應不同的內容或頁面的任務交給前端來做，之前是通過服務端根據url不同返回不同的頁面來實現。
* 利用H5的history.pushState?和?history.replaceState?，這兩個history新增的api，為前端操控瀏覽器歷史棧提供了可能性
* 這兩個Api都會操作瀏覽器的歷史棧，而不會引起頁面的刷新。
* 不同的是，pushState會增加一條新的歷史記錄，而replaceState則會替換當前的歷史記錄。
應用：單頁面應用
優點和缺點：
    * 優點： 用戶體驗好，不需要每次向服務器發送請求請求頁面數據，響應快
    * 缺點：使用瀏覽器的前進，后退鍵的時候會重新發送請求，沒有合理地利用緩存，

hash值得由來

歷史：
    1、基于Ajax 的 Web 應用最為明顯的特征在于使用了瀏覽器內部原生支持的 XMLHttpRequest對象與后臺服務器進行數據通。
    2、由于這種通信方式不需要頁面的刷新動作，因而無論與后臺發生了多少次通信，瀏覽器的 URL 會一直保持在初始地址不變。
    3、這隨之而來的一個問題便是不斷變化的頁面狀態信息無法記錄到瀏覽器的歷史記錄堆棧中，從而使得用戶無法通過瀏覽器的前進 / 后退按鈕在不同狀態頁面間進行切換。

解決思路：

瀏覽器能夠支持在用戶訪問過的頁面間進行前進 / 后退的操作，依賴于內部維持的 history 對象。
出于安全性的考慮，瀏覽器并不允許 JavaScript 腳本對該對象進行增刪改之類寫操作，
而只是可以通過 history. back/forward() 等方法進行訪問。既然在頁面狀態發生變化時，
無法通過腳本直接去影響瀏覽器的歷史信息，那么只有通過 URL 的變化來觸發瀏覽器增加一條新的歷史記錄。
這也就是說需要將 Ajax 應用的不同頁面狀態與 URL 進行一種一對一的映射，并且能夠在回退或前進到某一 URL 之時，
應用本身能夠在頁面無刷新的情況下跳轉到正確的頁面狀態。如何對 Ajax 應用的初始 URL 進行改變，
而同時這種變化的切換又不會引起頁面的重新加載呢？答案只有一個，那就是借助用于頁面內資源片段定位目的
的“片段標識符”（fragment identifier），即 URL 中“#”符號后的字符串（hash string）。當瀏覽器向
服務器端請求資源時，片段標識符并不會連同 base URL 一同發往服務器端，而只是在得到服務器返回的結果
之后幫助瀏覽器快速定位到被相應的錨點（anchor）所標識的資源片段，即使無法找個對應的錨點，瀏覽器也并
不會報錯。正是基于瀏覽器的這一特性，構建片段標識符與頁面狀態之間的映射關系成為了解決此類問題的基礎。

hash值

將任意長度的二進制字符串通過一定的算法映射成一個固定長度的較小二進制字符串，這個字符串就是對應的hash值，主要特點就是唯一的，不可逆的。

前端路由的hash值(#)----->angular

hash通常應用在spa單頁面應用中。因為通過不同的hash值映射的url來是的瀏覽器添加一條不同的url歷史記錄。

通過瀏覽器的pushstate、replaceState來操作，請求不同的瀏覽器記錄達到請求不同的頁面的效果

H5中提供的兩個操作hash值得API來操作hash值

window.location.hash讀取#值

window.onhashchange = func 監聽hash改變

GPU云服務器云服務器前端與后端 html前端與后端前端與后端區別 web前端與后端

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/84421.html

前端框架模式的變遷

摘要：現在在前端的框架都是的模式，還有像和之類的變種獨特的單向數據流框架。只要將數據流進行規范，那么原來的模式還是大有可為的。我們可以來看一下，框架的圖示從圖中，我們可以看到形成了一條到，再到，之后是的，一條單向數據流。前言前端框架的變遷，體系架構的完善，使得我們只知道框架，卻不明白它背后的道理。我們應該抱著一顆好奇心，在探索框架模式的變遷過程中，體會前人的一些理解和思考本篇將講述的是...

ssshooter 2019-08-22 11:11 評論0 收藏0
單頁應用的部署方案

摘要：所以單頁應用的部署，需要將所有的頁面請求都返回，瀏覽器下載了后會自動解析并導航到對應頁面。總結單頁應用與以前的常規多頁面應用還是有區別的，開發過程與后端解耦了，同時會出現跨域鑒權以及應用部署的問題。本文同步發布于我的個人博客上 - 單頁應用的部署方案本文主要簡單講一下單頁應用的開發及部署方法，默認你懂一些服務端知識及nginx知識，如果有任何可以在下方評論留言。單頁應用 SPA（...

yanbingyun1990 2019-07-25 14:45 評論0 收藏0
構建前端項目

摘要：解決思路服務器端渲染服務器端和前端公用同一個應用，然后通過構建工具及配置，確定哪些組件需要再服務器端渲染，那些組件需要再客戶端渲染。服務器端渲染，由框架與構建工具配合，并依據一定的項目結構和編碼方式，共同運行。分離為什么需要前后端分離、web服務器與static服務器分離: 前端與后端耦合 (需求) 自動化、工程化的構建前端的代碼 (基礎條件) 模塊化、組件化，項目共享代碼 (...

mindwind 2019-08-23 13:51 評論0 收藏0
細說 Vue 組件的服務器端渲染

摘要：所以，這次就來聊聊組件的服務器端渲染。這種模式下，后端只提供接口，傳統的服務器端路由模板渲染則都有層接管。這樣，前端開發人員可以自由的決定哪些組件需要在服務器端渲染，哪些組件可以放在客戶端渲染，前后端完全解耦，但又保留了服務器端渲染的功能。細說 Vue 組件的服務器端渲染聲明：需要讀者對 NodeJs、Vue 服務器端渲染有一定的了解現在，前后端分離與客戶端渲染已經成為前端開發的...

reclay 2019-08-23 17:51 評論0 收藏0