今天就跟大家聊聊有關(guān)怎么實(shí)現(xiàn)ssr服務(wù)端渲染，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。
什么是ssr
最初聽說有單頁面的服務(wù)端渲染的時(shí)候，就理解為類似傳統(tǒng)的服務(wù)端路由+模板渲染，只是需要用單頁面應(yīng)用的框架寫。后面尋思這樣好像有點(diǎn)傻，再一了解，原來只是在首次加載的時(shí)候，后端進(jìn)行當(dāng)前路徑頁面的組件渲染和數(shù)據(jù)請求，組裝成html返回給前端，用戶就能很快看到看到頁面，當(dāng)html中的js資源加載完成后，剩下執(zhí)行和運(yùn)行的就是一般的單頁面應(yīng)用。 所以ssr是后端模板渲染和單頁面的組合。 ssr有兩種模式，單頁面和非單頁面模式，第一種是后端首次渲染的單頁面應(yīng)用，第二種是完全使用后端路由的后端模版渲染模式。他們區(qū)別在于使用后端路由的程度。
優(yōu)勢
ssr的兩個(gè)明顯的優(yōu)勢：首次加載快和seo。 為什么說首次加載快呢。 一個(gè)普通的單頁面應(yīng)用，首次加載的時(shí)候需要把所有相關(guān)的靜態(tài)資源加載完畢，然后核心js才會(huì)開始執(zhí)行，這個(gè)過程就會(huì)消耗一定的時(shí)間，接著還會(huì)請求網(wǎng)絡(luò)接口，最終才能完全渲染完成。
ssr模式下，后端攔截到路由，找到對應(yīng)組件，準(zhǔn)備渲染組件，所有的js資源在本地，排除了js資源的網(wǎng)絡(luò)加載時(shí)間，接著只需要對當(dāng)前路由的組件進(jìn)行渲染，而頁面的ajax請求，可能在同一臺(tái)服務(wù)器上，如果是的話速度也會(huì)快很多。最后后端把渲染好的頁面反回給前端。 注意：頁面能很快的展示出來，但是由于當(dāng)前返回的只是單純展示的dom、css，其中的js相關(guān)的事件等在客戶端其實(shí)并沒有綁定，所以最終還是需要js加載完以后，對當(dāng)前的頁面再進(jìn)行一次渲染，稱為同構(gòu)。 所以ssr就是更快的先展示出頁面的內(nèi)容，先讓用戶能夠看到。 為什么seo友好呢，因?yàn)樗阉饕媾老x在爬取頁面信息的時(shí)候，會(huì)發(fā)送HTTP請求來獲取網(wǎng)頁內(nèi)容，而我們服務(wù)端渲染首次的數(shù)據(jù)是后端返回的，返回的時(shí)候已經(jīng)是渲染好了title，內(nèi)容等信息，便于爬蟲抓取內(nèi)容。
如何實(shí)現(xiàn)
大致對ssr有了一個(gè)了解，我們現(xiàn)在需要對實(shí)現(xiàn)整理一下大致實(shí)現(xiàn)思路和流程。
1.選擇一個(gè)單頁面框架（我目前選擇的是react）
2.選擇node服務(wù)端框架（我目前選擇的是koa2）
3.實(shí)現(xiàn)核心邏輯，讓node服務(wù)端能夠路由和渲染單頁面組件（這一點(diǎn)分為很多小實(shí)現(xiàn)點(diǎn)，后面說）
4.優(yōu)化開發(fā)和發(fā)布環(huán)境自動(dòng)化構(gòu)建工具（webpack）
開始實(shí)現(xiàn)之前創(chuàng)建一個(gè)react-ssr項(xiàng)目，項(xiàng)目下創(chuàng)建client和server目錄用于寫客戶端和服務(wù)端代碼，webpack目錄用于weppack文件配置。
1.react應(yīng)用
安裝react依賴，在client中創(chuàng)建好一個(gè)基礎(chǔ)的react文件夾結(jié)構(gòu)，并寫好一個(gè)可以運(yùn)行的有路由配置的應(yīng)用，client文件目錄如下：
2.server應(yīng)用
安裝koa和相關(guān)依賴，在server中創(chuàng)建好一個(gè)基礎(chǔ)的服務(wù)端文件夾結(jié)構(gòu)，并寫好一個(gè)簡單的可運(yùn)行的后端應(yīng)用服務(wù)。server文件夾如下：
3.核心實(shí)現(xiàn)
因?yàn)橛袀}庫代碼就不對基礎(chǔ)代碼做解釋，現(xiàn)在我們有一個(gè)可以單獨(dú)運(yùn)行的react單頁面應(yīng)用和一個(gè)后端應(yīng)用，他們都有各自的路由。接下來我們做改造，實(shí)現(xiàn)ssr的單頁面模式（非單頁面模式僅僅是做部分調(diào)整，因此這里只講實(shí)現(xiàn)單頁面模式）。
核心實(shí)現(xiàn)分為以下幾步：
1） 后端攔截路由，根據(jù)路徑找到需要渲染的react頁面組件X
2）調(diào)用組件X初始化時(shí)需要請求的接口，同步獲取到數(shù)據(jù)后，使用react的renderToString方法對組件進(jìn)行渲染，使其渲染出節(jié)點(diǎn)字符串。
3）后端獲取基礎(chǔ)html文件，把渲染出的節(jié)點(diǎn)字符串插入到body之中，同時(shí)也可以操作其中的title，script等節(jié)點(diǎn)。返回完整的html給客戶端。
4）客戶端獲取后端返回的html，展示并加載其中的js，最后完成react同構(gòu)。
1）我們在客戶端寫react的時(shí)候，router常規(guī)的會(huì)定義一個(gè)數(shù)組，存放組件和對應(yīng)的path，然后注冊路由，如下：
上面說過，實(shí)現(xiàn)ssr就是實(shí)現(xiàn)單頁面應(yīng)用+首次服務(wù)端渲染，所以我們本身就是做的一個(gè)單頁面應(yīng)用。 現(xiàn)在實(shí)現(xiàn)了單頁面應(yīng)用，需要實(shí)現(xiàn)首次服務(wù)端渲染。 服務(wù)端的應(yīng)用啟動(dòng)以后，接受到url請求，比如訪問 http://localhost:9999/ ,后端服務(wù)獲取到當(dāng)前的path為/，這個(gè)時(shí)候我們就希望后端找到配置path為‘/'的上圖的Index組件，對其進(jìn)行渲染。 我們在client的router文件夾中建立兩個(gè)js文件index和pages：
pages 里配置路由路徑和組件的映射，代碼大致如下，使其能被客戶端路由和服務(wù)端路由同時(shí)使用。
在server路由中代碼大致是這樣的，在服務(wù)端獲取到get請求以后，匹配路徑，如果路徑path是有映射頁面組件的，獲取到此組件并渲染，這就是我們的第一步：后端攔截路由，根據(jù)路徑找到需要渲染的react頁面組件。
2）如上圖，匹配到組件以后，執(zhí)行了組件的getInitialProps方法（和nextjs的命名保持一致），此方法是一個(gè)封裝的靜態(tài)方法，主要用于獲取初始化所需要的ajax數(shù)據(jù)，在服務(wù)端會(huì)同步獲取，而后通過ssrData參數(shù)傳入組件prorps并執(zhí)行組件渲染。 此方法在客戶端依然是異步請求。 這一步比較重要，為什么我們需要一個(gè)靜態(tài)方法，而不是直接把請求寫在willmount中呢。 因?yàn)樵诜?wù)端使用renderToString渲染組件時(shí)，生命周期只會(huì)執(zhí)行到willmount之后的第一次render，在willmount內(nèi)部，請求是異步的，第一次render完成的時(shí)候，異步的數(shù)據(jù)都沒有獲取到，這個(gè)時(shí)候renderToString就已經(jīng)返回了。 那我們頁面的初始化數(shù)據(jù)就沒有了，返回的html不是我們所期望的。 因此定義了一個(gè)靜態(tài)方法，在組件實(shí)例化之前獲取到這個(gè)方法，同步執(zhí)行，數(shù)據(jù)獲取完成后，通過props把數(shù)據(jù)傳入給組件進(jìn)行渲染。 那么這個(gè)方法是如何實(shí)現(xiàn)的呢？ 我們根據(jù)代碼截圖來看base.js：
首先在client的pages里新建一個(gè)base組件，base繼承React.Component，所有pages里的頁面組件都需要繼承這個(gè)base，base有一個(gè)靜態(tài)方法getInitialProps，此方法主要是返回組件初始化需要的異步數(shù)據(jù)。 如果有初始化的ajax請求，就應(yīng)該重寫在此方法里，并且return數(shù)據(jù)對象。 constructor判斷了頁面組件是否有初始化定義的state靜態(tài)方法，有的話傳遞給組件實(shí)例化的state對象，如果props有傳入ssrData，把ssrData傳遞值給組件state對象。 base中的componentWillMount會(huì)判斷是否還需要去執(zhí)行g(shù)etInitialProps方法，如果在服務(wù)端渲染的時(shí)候，數(shù)據(jù)已經(jīng)在組件實(shí)例化之前同步獲取并傳入了props，所以忽略。 如果在客戶端環(huán)境，分兩種情況，第一種：用戶第一次進(jìn)到頁面，這時(shí)候是服務(wù)端去請求的數(shù)據(jù)，服務(wù)端獲取到數(shù)據(jù)后在服務(wù)端渲染組件，同時(shí)也會(huì)把數(shù)據(jù)存放在html的script代碼中，定義一個(gè)全局變量ssrData,如下圖，react在注冊單頁面應(yīng)用并且同構(gòu)的時(shí)候會(huì)把全局ssrData傳遞給頁面組件，這個(gè)時(shí)候頁面組件在客戶端同構(gòu)渲染的時(shí)候，就可以延續(xù)使用服務(wù)端之前的數(shù)據(jù)，這樣也保持了同構(gòu)的一致性，也避免了一次重復(fù)請求。 第二種情況：就是當(dāng)前用戶在單頁面之中切換路由，這樣就沒有服務(wù)端渲染，那么就執(zhí)行g(shù)etInitialProps方法，把數(shù)據(jù)直接返回給state，幾乎等同于在willmount中執(zhí)行請求。 這樣封裝我們就可以用一套代碼兼容服務(wù)端渲染和單頁面渲染。
client/app.js
再看看如何寫頁面組件，下面是頁面組件Index的截圖，Index繼承Base，定義了靜態(tài)state，組件constructor方法會(huì)把此對象傳遞給組件實(shí)例化的state對象中，之所以用靜態(tài)方法來寫默認(rèn)數(shù)據(jù)，是想保證定義的默認(rèn)state先傳遞給實(shí)例對象的state，接口請求傳遞的props數(shù)據(jù)后傳遞給實(shí)例對象的state。 為什么不直接寫state屬性而要加static，因?yàn)閟tate屬性會(huì)執(zhí)行在constructor之后，這樣會(huì)覆蓋constructor定義的state，也就是會(huì)覆蓋我們getInitialProps返回的數(shù)據(jù)。
注意：在服務(wù)端渲染環(huán)境下，執(zhí)行renderToString的時(shí)候，組件會(huì)被實(shí)例化，并且返回字符串形式的dom，這個(gè)過程react組件的生命周期只會(huì)執(zhí)行到willmount之后的render。
3）我們寫好一個(gè)html文件，大致如下。 當(dāng)前已經(jīng)渲染出了相應(yīng)的節(jié)點(diǎn)字符串，后端需要返回html文本，內(nèi)容應(yīng)該包含標(biāo)題，節(jié)點(diǎn)和最后需要加載的打包好的js，依次去替換html占位部分。
index.html
server/router.js
4）最后客戶端js加載完成后，會(huì)運(yùn)行react，并且執(zhí)行同構(gòu)方法ReactDOM.hydrate，而不是平時(shí)用的ReactDOM.render。
以下是首次渲染過程大致流程圖，點(diǎn)擊查看大圖
css處理
現(xiàn)在我們已經(jīng)完成了最核心的邏輯，但是有一個(gè)問題。 我發(fā)現(xiàn)在后端渲染組件的時(shí)候，style-loader會(huì)報(bào)錯(cuò)，style-loader會(huì)找到組件依賴的css，并在組件加載時(shí)，把style載入到html header中，但是我們在服務(wù)端渲染的時(shí)候，沒有window對象，因此style-loader內(nèi)部代碼會(huì)報(bào)錯(cuò)。 服務(wù)端webpack需要移除style-loader，用其他方法代替，后來我把樣式賦值給組件靜態(tài)變量，然后通過服務(wù)端渲染一并返回給前端，但是有個(gè)問題，我只能拿到當(dāng)前組件的樣式，子組件的樣式?jīng)]辦法拿到，如果要給子組件再添加靜態(tài)方法，再想辦法去取，那就太麻煩了。 后來我找到了一個(gè)庫isomorphic-style-loader可以支持我們想要的功能，看了下它的源碼和使用方法，通過高階函數(shù)把樣式賦值給組件，然后利用react的Context，拿到當(dāng)前需要渲染的所有組件的樣式，最后把style插入到html中，這樣解決了子組件樣式無法導(dǎo)入的問題。 但是我覺得有點(diǎn)麻煩，首先需要定義所有組件的高階函數(shù)和引入這個(gè)庫，然后在router之中需要寫相關(guān)代碼收集style，最后插入到html中。 后來我定義了一個(gè)ProcessSsrStyle方法，入?yún)⑹莝tyle文件，邏輯是判斷環(huán)境，如果是服務(wù)端把style加載到當(dāng)前組件的dom中，如果是客戶端就不處理（因?yàn)榭蛻舳擞衧tyle-loader）。 實(shí)現(xiàn)和使用非常簡單，如下：
ProcessSsrStyle.js
使用：
服務(wù)端返回html的內(nèi)容如下，用戶馬上能夠看到完整的頁面樣式，而當(dāng)客戶端react同構(gòu)完成后，dom會(huì)被替換為純dom，因?yàn)镻rocessSsrStyle方法在客戶端不會(huì)輸出style，最終style-loader執(zhí)行后header中也會(huì)有樣式，，頁面不會(huì)出現(xiàn)不一致的變化，對于用戶來說這一切都是無感的。
至此，最核心的功能已經(jīng)實(shí)現(xiàn)，但是在后來的開發(fā)中，我發(fā)現(xiàn)事情還并沒有那么簡單，因?yàn)殚_發(fā)環(huán)境似乎太不友好了，開發(fā)效率低，需要手動(dòng)重啟。
開發(fā)環(huán)境
先說說最初的開發(fā)環(huán)境如何工作：
npm run dev啟動(dòng)開發(fā)環(huán)境
webpack.client-dev.js打包服務(wù)端代碼,代碼會(huì)被打包到dist/server中
webpack.server-dev.js打包客戶端代碼,代碼會(huì)被打包到dist/client中
啟動(dòng)服務(wù)端應(yīng)用，端口9999
啟動(dòng)webpack-dev-server， 端口8888
webpack打包后，啟動(dòng)了兩個(gè)服務(wù)，一個(gè)是服務(wù)端的app應(yīng)用、端口為9999，一個(gè)是客戶端的dev-server、端口為8888，dev-server會(huì)監(jiān)聽和打包c(diǎn)lient代碼，可以在客戶端代碼更新的時(shí)候，實(shí)時(shí)熱更新前端代碼。 當(dāng)訪問localhost:9999時(shí)，server會(huì)返回html，我們的server返回的html中的js腳本路徑是指向的dev-serve端口的地址，如下圖。 也就是說，客戶端的程序和服務(wù)端的程序被分別打包，并且運(yùn)行兩個(gè)不同的端口服務(wù)。
在生產(chǎn)環(huán)境下，因?yàn)椴恍枰猟ev-server去監(jiān)聽和熱更新，因此只一個(gè)服務(wù)就足夠， 如下圖，服務(wù)端注冊靜態(tài)資源文件夾：
server/app.js
目前的構(gòu)建系統(tǒng)，區(qū)分了生產(chǎn)環(huán)境和開發(fā)環(huán)境，現(xiàn)在的開發(fā)環(huán)境構(gòu)建是沒有什么問題的。 但是開發(fā)環(huán)境問題就比較明顯，存在的大問題是服務(wù)端沒有熱更新或者重新打包重啟。 這樣會(huì)導(dǎo)致很多問題，最嚴(yán)重的就是前端已經(jīng)更新了組件，但是服務(wù)端并沒有更新，所以在同構(gòu)的時(shí)候會(huì)出現(xiàn)不一致，就會(huì)導(dǎo)致報(bào)錯(cuò)，有些報(bào)錯(cuò)會(huì)影響運(yùn)行，解決辦法只有重啟。 這樣的開發(fā)體驗(yàn)是無法忍受的。 后來我開始考慮做服務(wù)端的熱更新。
監(jiān)聽、打包、重啟
最初我的方法是監(jiān)聽修改，打包然后重啟應(yīng)用。 還記得我們的client/router/pages.js文件嗎，客戶端和服務(wù)端的路由都引入了這個(gè)文件，所以服務(wù)端和客戶端的打包依賴都有pages.js，因此所有pages的組件相關(guān)的依賴都可以被客戶端和服務(wù)端監(jiān)聽，當(dāng)一個(gè)組件更新了，dev-server已經(jīng)幫助我們監(jiān)聽和熱更新了客戶端代碼，現(xiàn)在我們要自己來處理以下如何更新和重啟服務(wù)端代碼。 其實(shí)方法很簡單，就是在服務(wù)端打包配置里開啟監(jiān)聽，然后在插件配置中，寫一個(gè)重啟的插件，插件代碼如下：
當(dāng)webpack首次運(yùn)行之后，插件會(huì)啟動(dòng)一個(gè)子進(jìn)程，運(yùn)行app.js，當(dāng)文件發(fā)生變動(dòng)后，再次編譯，判斷是否有子進(jìn)程，如果有殺掉子進(jìn)程，然后重啟子進(jìn)程，這樣就實(shí)現(xiàn)了自動(dòng)重啟。 因?yàn)榭蛻舳撕头?wù)端是兩個(gè)不同的打包服務(wù)和配置，當(dāng)文件被修改，他們同時(shí)會(huì)重新編譯，為了保證編譯后運(yùn)行符合預(yù)期，要保證服務(wù)端先編譯完成，客戶端后編譯完成，所以在客戶端的watch配置里，增加一點(diǎn)延遲，如下圖，默認(rèn)是300毫秒，所以服務(wù)端是300毫秒后執(zhí)行編譯，而客戶端是1000毫秒后執(zhí)行編譯。
現(xiàn)在解決了重啟問題，但是我覺得還不夠，因?yàn)樵陂_發(fā)的大部分時(shí)間里pages.js中組件，也就是展示端的代碼更新頻率會(huì)很高，如果老是去重啟編譯后端的代碼，我覺得效率太低。 因此我覺得再做一次優(yōu)化。
抽離client/router/pages單獨(dú)打包
流程應(yīng)該是這樣的，增加一個(gè)webpack.server-dev-pages.js配置文件，單獨(dú)監(jiān)聽和打包出dist/pages，服務(wù)端代碼判斷如果是開發(fā)環(huán)境，在路由監(jiān)聽方法中每次執(zhí)行都重新獲取dist/pages包，服務(wù)端監(jiān)聽配置忽略client文件夾。 看起來有點(diǎn)懵逼，其實(shí)最終的效果就是當(dāng)pages中依賴的組件發(fā)生了更新，webpack.server-dev-pages.js重新編譯并打包到dist/pages中，服務(wù)端app不編譯和重啟，只需要在服務(wù)端app路由中重新獲取最新的dist/pages包，就保證了服務(wù)應(yīng)用更新了所有客戶端組件，而服務(wù)端應(yīng)用并不會(huì)編譯和重啟。 當(dāng)服務(wù)端本身的代碼發(fā)生了修改，還是會(huì)自動(dòng)編譯和重啟。 所以最終我們的開發(fā)環(huán)境需要啟動(dòng)3個(gè)打包配置
webpack.server-dev-pages
webpack.server-dev
webpack.client-dev
server/router，如何清除和更新pages包
至此，比較滿意的開發(fā)環(huán)境基本實(shí)現(xiàn)了。 后來又覺得每次更新css都需要去重新打包后端的pages也沒有必要，加上同構(gòu)的時(shí)候css不一致，僅僅只有警告，沒有實(shí)質(zhì)影響，因此我在server-dev-pages中忽略了less文件（因?yàn)槲矣玫膌ess）。 這樣會(huì)導(dǎo)致一個(gè)問題，因?yàn)闆]有更新pages，所以頁面會(huì)刷新時(shí)會(huì)先展示舊的樣式，然后同構(gòu)完成又立馬變成新樣式，在開發(fā)環(huán)境中這一瞬間是可以接受的，也不影響什么。 但是避免了無謂的編譯。
沒有做的事情
封裝成一個(gè)更有包裹性的三方腳手架
css作用域控制
封裝性更強(qiáng)的webpack配置
開發(fā)環(huán)境下，圖片路徑會(huì)出現(xiàn)不一致
最初做自己小站的目的是學(xué)習(xí)，加上自己使用，因此有太多個(gè)性的東西。 從自己的小站中抽離了出來，已經(jīng)刪去了很多包和代碼，只為了讓他人更能快速理解其中的核心代碼。 代碼中有很多注釋都能幫助他人理解，如果大家想使用當(dāng)前庫開發(fā)一個(gè)自己的小站，是完全可以的，也可以幫助大家更好的理解它。 如果是用于商業(yè)項(xiàng)目，推薦nextjs。 css沒有做作用域控制，因此如果想隔離作用域，手動(dòng)添加上層css隔離，比如.index{ ..... }包裹一層，或者嘗試自己引入三方包。 webpack通用的配置可以封裝成一個(gè)文件，然后在每個(gè)文件里引入，再個(gè)性修改。 但是之前看其他代碼的時(shí)候發(fā)現(xiàn)，這種方法，會(huì)增加閱讀難度，加上本身配置內(nèi)容不多，所以不做封裝，看起來更直觀。 開發(fā)環(huán)境下，圖片路徑會(huì)出現(xiàn)不一致，比如客戶端地址請求地址是localhost...assets/xx.jpg,而服務(wù)端是assets/xx.jpg，可能會(huì)有警告，但是不影響。 因?yàn)橹皇且粋€(gè)是絕對路徑，一個(gè)是相對路徑。
看完上述內(nèi)容，你們對怎么實(shí)現(xiàn)ssr服務(wù)端渲染有進(jìn)一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。
重慶分公司
重慶分公司
