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

目前創(chuàng)新互聯(lián)公司已為數(shù)千家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)頁空間、網(wǎng)站托管維護(hù)、企業(yè)網(wǎng)站設(shè)計、二七網(wǎng)站維護(hù)等服務(wù)，公司將堅持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

前言

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

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

同構(gòu)

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

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

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

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

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

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

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

支持 Post 請求

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

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

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

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

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

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

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

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

但這個頁面不僅會提供給 AirPay 使用，還會提供給 Shopee 使用，需要兼容兩套 JS Bridge，有點兒得不償失。

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

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

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

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

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

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

缺點

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

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

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

但實際上帶來的收益幾乎為零，因為我們不需要 SEO，也不需要提高首屏加載速度。

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

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

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

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

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

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

因為 Nuxt 初始化的時候會把這些數(shù)據(jù)存到 store 里面，后續(xù)再怎么刷新，這個文件也不會在服務(wù)端重新加載，因為模塊會被 Node 緩存起來，所以日期就不會更新。

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

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