javascript使用服務(wù)端渲染的示例分析

小編給大家分享一下javascript使用服務(wù)端渲染的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

前言

前陣子有搞了 React 服務(wù)端渲染的項(xiàng)目，是否應(yīng)該用這個(gè)主要還是看場(chǎng)景吧。

比較適用于大家常說的 SEO 和首屏渲染這些，一般都是 toc 的業(yè)務(wù)才會(huì)需要用到。

同構(gòu)

現(xiàn)代框架的服務(wù)端渲染和 jsp、php 這些還是有不少區(qū)別的。因?yàn)?nextjs 和 nuxtjs 這種不僅僅是服務(wù)端渲染，它們還是同構(gòu)框架。

什么是同構(gòu)呢？就是一份代碼既可以跑在瀏覽器端，也可以跑在服務(wù)端。這得益于 NodeJS 在服務(wù)端的流行。

傳統(tǒng) jsp、php、django 這些服務(wù)端渲染框架都是返回 html 字符串，類似于傳統(tǒng)的 MPA 多頁面模式。所以切換頁面的時(shí)候就會(huì)刷新，重新請(qǐng)求 css 和 js 文件，用戶體驗(yàn)比較差。

而現(xiàn)在流行的前端開發(fā)模式都是 SPA 單頁面，基于 H5 的 History 來實(shí)現(xiàn)切換頁面無刷新，這樣可以帶來更好的用戶體驗(yàn)。

所以 nextjs 和 nuxtjs 不僅支持服務(wù)端渲染，還支持 SPA，常用的是對(duì)首頁進(jìn)行服務(wù)端渲染，其他頁面依然保持 SPA 的無刷新訪問模式。

我們這邊就有使用 Django 來編寫的頁面，維護(hù)起來很痛苦。因?yàn)闊o法說清楚哪些是前端負(fù)責(zé)的，哪些是后端負(fù)責(zé)的。所以為了維護(hù)這個(gè)，前端和后端都去要學(xué)習(xí) Python 和 Django，大大提高了維護(hù)成本。

實(shí)際應(yīng)用場(chǎng)景的話，我們這里有幾種場(chǎng)景就比較適合用服務(wù)端渲染。

支持 Post 請(qǐng)求

一個(gè)是重構(gòu)的 h6 頁面，項(xiàng)目以前是新加坡團(tuán)隊(duì)用 Python + Django 寫的，所以有些頁面是第三方網(wǎng)站 Post 提交表單打開的。

我們重構(gòu)后的 H5 頁面都掛在騰訊云 CDN 上面，不支持用 Post 打開的。為什么不改成 Get 呢？因?yàn)檫@是以前他們協(xié)定的，然后銀行都是爸爸，他們不會(huì)為了我們?nèi)ジ膮f(xié)議的。

頁面功能都是比較簡(jiǎn)單的，所以為了趕上重構(gòu)的時(shí)間線，當(dāng)時(shí)旁邊的小伙伴用 Express + EJS 實(shí)現(xiàn)了一版，只支持 ES5 的語法。

后續(xù)需求經(jīng)歷幾次變更，想在原來的頁面上加功能都比較麻煩。比如我想實(shí)現(xiàn) JS Bridge，我只能用 microbundle 把現(xiàn)有的 npm 包打成一個(gè) umd 文件，然后用 script 標(biāo)簽引入。

動(dòng)態(tài)渲染標(biāo)題

前陣子遇到了另一個(gè)需求，我需要為多家銀行實(shí)現(xiàn)同樣的 H5 頁面，功能基本上都是一樣的，但 App 頭部需要展示不同銀行的名字。

在我們 AirPay App 里面，客戶端在打開 webview 的時(shí)候會(huì)去讀取我們 HTML 里面的 title，將其設(shè)置為原生頭部的標(biāo)題。

如果我在代碼里面使用 document.title 的方式動(dòng)態(tài)設(shè)置就不會(huì)生效，只能通過 JS Bridge 來動(dòng)態(tài)設(shè)置頭部。

但這個(gè)頁面不僅會(huì)提供給 AirPay 使用，還會(huì)提供給 Shopee 使用，需要兼容兩套 JS Bridge，有點(diǎn)兒得不償失。

但如果使用服務(wù)端直出的形式，就可以在服務(wù)端直接判斷好需要渲染的標(biāo)題，設(shè)置到 HTML 的 title 里面。這就是另一種適合的業(yè)務(wù)場(chǎng)景了。

所以在之前項(xiàng)目基礎(chǔ)上添加了 React 服務(wù)端渲染的功能，支持用 React 開發(fā)同構(gòu)應(yīng)用。這里也沒有用 Next，只是自己實(shí)現(xiàn)的一套同構(gòu)。

大致實(shí)現(xiàn)思路是用 isomorphic-style-loader 和 universal-router 來處理樣式和路由的同構(gòu)，服務(wù)端獲取到數(shù)據(jù)后輸出到 window._INITIAL_STATE__ 里面，在瀏覽器獲取這個(gè)初始化數(shù)據(jù)實(shí)現(xiàn)數(shù)據(jù)同構(gòu)的。

同時(shí)也保留了原來的 EJS 模板，都是基于 Express 路由分發(fā)的，既可以渲染用 EJS 渲染，也可以用 React 服務(wù)端直出。

一期的這個(gè)頁面是掛在騰訊云 CDN 上面的，二期使用了服務(wù)端渲染，可以明顯感覺到加載速度變快了很多，畢竟以前還是會(huì)展示一個(gè) loading 圖。

在進(jìn)程守護(hù)方面，整個(gè)部門的 Node 服務(wù)都是用大佬寫的 Node Agent 來做，也經(jīng)受住了各種大促的考驗(yàn)。

缺點(diǎn)

當(dāng)然了，服務(wù)端渲染也不應(yīng)該濫用。

比如我們的內(nèi)部后臺(tái)管理系統(tǒng)就上了 Nuxt，現(xiàn)在每次本地構(gòu)建要花10分鐘，非常影響開發(fā)效率。

Nuxt 功能還是非常強(qiáng)大的，比如會(huì)根據(jù)路由動(dòng)態(tài)拆分構(gòu)建文件、鼠標(biāo)放到 Nuxt-link 路由組件上面就會(huì)預(yù)加載 JS 文件等等。

但實(shí)際上帶來的收益幾乎為零，因?yàn)槲覀儾恍枰?SEO，也不需要提高首屏加載速度。

幾乎組里面每個(gè)人都有嘗試用各種手段去優(yōu)化構(gòu)建，但效果不是很明顯。直到最近開始做微前端拆分，才曲線解決這個(gè)問題。

除此之外，服務(wù)端渲染在寫法上也和客戶端渲染有一些區(qū)別，容易導(dǎo)致 bug。

比如下面在 Vuex 的 state 文件里面的這段代碼：

const date = moment().format('YYYY-MM-DD')
export default () => ({  
date
})

打開頁面的時(shí)候，時(shí)間應(yīng)該展示的是今天。哪怕頁面放置剛好跨天了，打開再刷新也應(yīng)該是當(dāng)天時(shí)間。

但在 Nuxt 里面，這個(gè)展示的日期就是你服務(wù)啟動(dòng)那天的日期，不管你怎么刷新，它永遠(yuǎn)不會(huì)變化。

因?yàn)?Nuxt 初始化的時(shí)候會(huì)把這些數(shù)據(jù)存到 store 里面，后續(xù)再怎么刷新，這個(gè)文件也不會(huì)在服務(wù)端重新加載，因?yàn)槟K會(huì)被 Node 緩存起來，所以日期就不會(huì)更新。

但在客戶端渲染里面，由于頁面刷新會(huì)導(dǎo)致瀏覽器端重新加載 JS 文件，這個(gè)日期也會(huì)重新計(jì)算。

以上是“javascript使用服務(wù)端渲染的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！