前端知識點

browserHistory和hashHistory

首先 browserHistory 其實使用的是 HTML5 的 History API,瀏覽器提供相應的接口來修改瀏覽器的歷史記錄树枫,不少方法還是實驗性的,而且 E10 以下不支持;而 hashHistory 是通過改變地址后面的 hash 來改變?yōu)g覽器的歷史記錄;

History API 提供了 pushState() 和 replaceState() 方法來增加或替換歷史記錄茂浮。而 hash 沒有相應的方法,所以并沒有替換歷史記錄的功能。但 react-router 通過 polyfill 實現(xiàn)了此功能席揽,具體實現(xiàn)沒有看顽馋,好像是使用 sessionStorage。

另一個原因是 hash 部分并不會被瀏覽器發(fā)送到服務端幌羞,也就是說不管是請求 #foo 還是 #bar 寸谜,服務只知道請求了 index.html 并不知道 hash 部分的細節(jié)。而 History API 需要服務端支持属桦,這樣服務端能獲取請求細節(jié)熊痴。

還有一個原因是因為有些應該會忽略 URL 中的 hash 部分,記得之前將 URL 使用微信分享時會丟失 hash 部分聂宾。

前端開發(fā)單頁應用果善,為什么在 url #后傳參

問號以及后面的結構瀏覽器通常稱為 Search,服務端通常稱為 Query系谐,這部分是會傳到服務器的巾陕。而井號以及后面的部分瀏覽器端是稱為 Hash,是不會傳到服務器上的纪他。

通常單頁面應用的路由及頁面間的傳參不需要服務器處理鄙煤,也就不需要傳給服務器。

最重要的一點是如果在 Search中傳參整個頁面是會刷新的止喷,而單頁面應用的設計就是想要避免用戶在使用過程中頁面刷新馆类。Hash 的修改通常就不會刷新。

例如從列表頁進入詳情頁弹谁,直接 js 獲取詳情頁內容然后直接在當前頁面顯示了詳情頁乾巧,這時候如果變更 url 前半部分會照成瀏覽器重新加載頁面。

當然現(xiàn)在新瀏覽器支持不重新加載頁面變更 url预愤,但是還是老問題沟于,為了兼容老瀏覽器很多還是只變更 # 后面。

? 傳參走的是 form 提交植康,瀏覽器認為 url 變了會刷新頁面的旷太,是同步的做法,現(xiàn)在都是異步销睁,查詢都是走 XHR 或者 fetch 的供璧,不需要刷新頁面,#傳參是個大框架都支持的路由傳參方法冻记,不過也有缺點睡毒,有些第三方 API 默認會過濾#傳的參數(shù),導致 redirect 失敗冗栗,比如微信的 API演顾,號稱是為了安全性

用#hash 還有個好處上面都沒提到供搀,就是 http 的 referer(引用) 會帶上?search,不會帶上#hash钠至。如果頁面資源多葛虐、?search 也很長的話,就會產生許多帶有很長?search 的 referer棉钧,浪費帶寬屿脐;而且?guī)в?search 的 referer 請求外部資源,還有可能把敏感信息暴露給第三方掰盘。

js 有什么原生的方法可以吧 object 轉為 string key=value 形式嗎摄悯?

例如對象 { test:1, test2:2 } 轉成字符串 test=1&test2=2

Object
 .entries(o)
 .reduce((arr, [k, v])
  => arr.concat(encodeURIComponent(k) + '=' + encodeURIComponent(v)), [])
 .join('&')

//在 Node.js 里自帶 querystring 模塊 
const querystring = require('querystring') 
querystring.stringify(obj)

渲染模式

以前后端渲染模式,訪問一個頁面---瀏覽器發(fā)出請求愧捕,服務器后臺讀取數(shù)據(jù)奢驯,渲染模板,瀏覽器拿到 HTML 開始渲染次绘,請求圖片等資源瘪阁,用戶看到一個完整網頁;
現(xiàn)在瀏覽器渲染模式邮偎,訪問一個頁面---瀏覽器發(fā)出請求管跺,從 CDN 或服務器得到靜態(tài)頁面(此頁面只包含極少部分頁面內容),瀏覽器開始渲染禾进,看到部分靜態(tài)內容豁跑,請求靜態(tài)資源,解析 js 腳本泻云,發(fā)出請求艇拍,服務器響應請求,返回數(shù)據(jù)宠纯,js 拿到數(shù)據(jù)卸夕,拼裝內容,瀏覽器渲染婆瓜,用戶看到完整網頁

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末快集,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子廉白,更是在濱河造成了極大的恐慌个初,老刑警劉巖,帶你破解...
    沈念sama閱讀 222,464評論 6 517
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件猴蹂,死亡現(xiàn)場離奇詭異勃黍,居然都是意外死亡,警方通過查閱死者的電腦和手機晕讲,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,033評論 3 399
  • 文/潘曉璐 我一進店門覆获,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人瓢省,你說我怎么就攤上這事弄息。” “怎么了勤婚?”我有些...
    開封第一講書人閱讀 169,078評論 0 362
  • 文/不壞的土叔 我叫張陵摹量,是天一觀的道長。 經常有香客問我馒胆,道長缨称,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 59,979評論 1 299
  • 正文 為了忘掉前任祝迂,我火速辦了婚禮睦尽,結果婚禮上,老公的妹妹穿的比我還像新娘型雳。我一直安慰自己当凡,他們只是感情好,可當我...
    茶點故事閱讀 69,001評論 6 398
  • 文/花漫 我一把揭開白布纠俭。 她就那樣靜靜地躺著沿量,像睡著了一般。 火紅的嫁衣襯著肌膚如雪冤荆。 梳的紋絲不亂的頭發(fā)上朴则,一...
    開封第一講書人閱讀 52,584評論 1 312
  • 那天,我揣著相機與錄音钓简,去河邊找鬼乌妒。 笑死,一個胖子當著我的面吹牛涌庭,可吹牛的內容都是我干的芥被。 我是一名探鬼主播,決...
    沈念sama閱讀 41,085評論 3 422
  • 文/蒼蘭香墨 我猛地睜開眼坐榆,長吁一口氣:“原來是場噩夢啊……” “哼拴魄!你這毒婦竟也來了?” 一聲冷哼從身側響起席镀,我...
    開封第一講書人閱讀 40,023評論 0 277
  • 序言:老撾萬榮一對情侶失蹤匹中,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后豪诲,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體顶捷,經...
    沈念sama閱讀 46,555評論 1 319
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 38,626評論 3 342
  • 正文 我和宋清朗相戀三年屎篱,在試婚紗的時候發(fā)現(xiàn)自己被綠了服赎。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片葵蒂。...
    茶點故事閱讀 40,769評論 1 353
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖重虑,靈堂內的尸體忽然破棺而出践付,到底是詐尸還是另有隱情,我是刑警寧澤缺厉,帶...
    沈念sama閱讀 36,439評論 5 351
  • 正文 年R本政府宣布永高,位于F島的核電站,受9級特大地震影響提针,放射性物質發(fā)生泄漏命爬。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 42,115評論 3 335
  • 文/蒙蒙 一辐脖、第九天 我趴在偏房一處隱蔽的房頂上張望饲宛。 院中可真熱鬧,春花似錦揖曾、人聲如沸落萎。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,601評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽练链。三九已至,卻和暖如春奴拦,著一層夾襖步出監(jiān)牢的瞬間媒鼓,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,702評論 1 274
  • 我被黑心中介騙來泰國打工错妖, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留绿鸣,地道東北人。 一個月前我還...
    沈念sama閱讀 49,191評論 3 378
  • 正文 我出身青樓暂氯,卻偏偏與公主長得像潮模,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子痴施,可洞房花燭夜當晚...
    茶點故事閱讀 45,781評論 2 361

推薦閱讀更多精彩內容