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