js在伺服器端渲染（js在伺服器端渲染不出來）

本文目錄一覽：

• 1、react.js在伺服器端渲染有什麼好處？渲染是怎麼個流程
• 2、react.js在伺服器端渲染有什麼好處
• 3、服務端渲染SSR之UmiJS預渲染
• 4、現在又流行服務端渲染html了，這是為何？
• 5、React 服務端渲染與預渲染

react.js在伺服器端渲染有什麼好處？渲染是怎麼個流程

服務端渲染與react沒有直接關係,你可以理解為服務端渲染時一段js，引入到react或者vue裡面都能使用，不引入也沒關係。 使用服務端渲染的場景是當我們要求渲染時間盡量快、頁面響應速度快時（優點），才會採用伺服器渲染，並且應該「按需」對頁面進reactjs在伺服器端渲染有什麼好處？渲染是怎麼個流程

react.js在伺服器端渲染有什麼好處

有些回答中提到CPU負載和node.js效率問題。伺服器端渲染固然耗CPU，但可以使用伺服器端緩存的方式解決，並不是每個用戶訪問都需要重新渲染一遍。而且伺服器端渲染甚至可以潛在地增加伺服器效率（這點在參考資料第二個里有提到，不過是純英文的，我有空會翻譯下）。2. 伺服器端和客戶端可以共享某些代碼，避免重複定義。這樣可以使結構更清晰，增加可維護性3. 首次載入頁面的速度加快。客戶端渲染的一個缺點是，當用戶第一次進入站點，此時瀏覽器中沒有緩存，需要下載代碼後在本地渲染，時間較長。而伺服器渲染則是，用戶在下載的已經是渲染好的頁面了，打開速度比本地渲染快。4. SEO。伺服器端渲染可以讓搜索引擎更容易讀取頁面的meta信息以及其他SEO相關信息，大大增加網站在搜索引擎中的可見度。其實並不一定要爭個好壞，伺服器端和客戶端渲染各有各的優缺點。建議根據實際需求，在某些頁面使用伺服器渲染，某些頁面使用客戶端渲染，以達到最佳解決方案。

我的伺服器用的是小鳥雲的，挺不錯的。

服務端渲染SSR之UmiJS預渲染

本文主要介紹 UmiJS 的預渲染功能。

服務端渲染（Server-Side Rendering），是指由 服務端 完成頁面的 HTML 結構拼接的頁面處理技術，發送到瀏覽器，然後為其綁定狀態與事件，成為完全可交互頁面的過程。

服務端渲染，首先得有後端伺服器（一般是 Node.js）才可以使用，而沒有後端伺服器的情況下，可以使用 預渲染 。

預渲染與服務端渲染唯一的不同點在於 渲染時機 ，服務端渲染的時機是在用戶訪問時執行渲染（即實時渲染，數據一般是最新的），預渲染的時機是在項目構建時，當用戶訪問時，數據不一定是最新的（ 如果數據沒有實時性，可以直接考慮預渲染 ）。

預渲染在構建時執行渲染，將渲染後的 HTML 片段生成靜態 HTML 文件。無需使用 web 伺服器實時動態編譯 HTML，適用於 靜態站點生成 。

Umi3 在 SSR 上做了大量優化及開發體驗的提升，具有以下特性：

默認情況下，服務端渲染時關閉的，可通過配置開啟：

服務端渲染的數據獲取方式與 SPA(單頁應用) 有所不同，為了讓客戶端和服務端都能獲取到同一份數據，Umi 提供了頁面級數據的預獲取。

每個頁面可能有單獨的數據預獲取邏輯，這裡我們會獲取頁面組件上的 getInitialProps 靜態方法，執行後將結果注入到該頁面組件的 props 中，如：

getInitialProps 有幾個固定參數：

為了結合數據流框架，我們提供了 modifyGetInitialPropsCtx 方法，由插件或應用來擴展 ctx 參數，以 dva 為例：

然後在頁面中，可以獲取到 store ：

同時也可以在自身應用中進行擴展：

同時可以使用 getInitialPropsCtx 將服務端參數擴展到 ctx 中，例如：

在使用的時候，就有 req 對象，不過需要注意的是，只在服務端執行時才有此參數：

則在執行 getInitialProps 方法時，除了以上兩個固定參數外，還會獲取到 title 和 store 參數。

關於 getInitialProps 執行邏輯和時機，需要注意：

執行 umi build ，除了正常的 umi.js 外，會多一個服務端文件： umi.server.js （相當於服務端入口文件）。然後在後端框架中，引用該文件：

render 方法參數和返回值如下：

完美兼容客戶端動態載入，配置如下：

@umijs/preset-react 插件集中已內置對標題的渲染，通過以下步驟使用：

@umijs/preset-react 插件集中已內置 dva

這時候 getInitialProps(ctx) 中的 ctx 就會有 store 屬性，可執行 dispatch ，並返回初始化數據。

Umi 同時支持對服務端和客戶端包大小的分析

現在又流行服務端渲染html了，這是為何？

1 一開始，html 就是後端渲染的。不過後端發現頁面中的 js 好麻煩（雖然簡單，但是坑多），於是讓公司招聘專門寫 js 的人，也就是前端

2 前端名義上是程序員，實際上就是在切圖（CSS）和做特效(JS)，所以所有程序員中前端工資最低，職位也最低。所以前後端的鄙視鏈就出現了

3 nodejs 和前端 mvc 的興起讓前端變得複雜起來，前端發現翻身的機會，於是全力支持這兩種技術，造成本不該做成 spa 的網站也成了 spa。慢慢地前後端分離運動從大公司開始興起，目的就是前端脫離後端的指指點點，獨立發展。（表面上是為了「代碼分離」，實際上是為了「人員分離」，也就是「前後端分家」，前端不再附屬於後端團隊）

4 spa 之後發現 seo 問題很大，而且首屏渲染速度賊慢，但是自己選的路再難走也要走下去，於是用 nodejs 在服務端渲染這一條路被看成是一條出路

5 其實這是第二個翻身的機會，如果 nodejs 伺服器渲染成為主流，其實就相當於前端把後端的大部分工作給搶了，工資壓過普通後端指日可待

6 然而結果是 nodejs 服務端渲染始終是小眾，因為後端也沒那麼脆弱，java php rails 十多年沉澱的技術豈是你說推翻就推翻的，已經運行多年的項目又豈是容你隨便用 nodejs 重寫的，另一方面 golang 等技術的興起也給 nodejs 不少壓力。最終只有少部分前端特彆強勢的團隊成功用上了 Node.js 做渲染（比如阿里的一些團隊），大部分公司依然是用 PHP 渲染 HTML。

7 於是 nodejs 退一步說好好好我不搶你們的工作，我只做中間層（大部分工作就是渲染頁面和調用後台介面），絕不越雷池。後端說算你識相。現在 nodejs 主要搞什麼微服務，也是為了搶後端還沒注意的市場。

你要看一門技術的發展主要應該看背後的人是誰，應用場景是哪些，最後才是技術細節。

React 服務端渲染與預渲染

仍是SPA

需要用到 react-router-config 這個庫，它可以根據 route 匹配到對應的組件，拿到當前route對應的組件是實現路由同步的關鍵，再通過組件的靜態API方法獲取介面數據

主要是在服務端通過組件的靜態API方法獲取介面數據後創建store，再通過 window. store = store 傳遞給前端

主要是要將前端的 js 文件附加在服務端渲染的模板 html 文件中

服務端渲染的應用場景：一般只是對重要的頁面，如首頁才會做，可以提高首屏載入速度，利於SEO。其他頁面實際上仍是CSR

預渲染不像伺服器渲染那樣即時編譯 HTML，它只在構建時為了特定的路由生成特定的幾個靜態頁面，等於我們可以通過 Webpack 插件將一些特定頁面組件 build 時就編譯為 html 文件，直接以靜態資源的形式輸出給搜索引擎。

1、SPA變為MPA

2、必須使用 History 路由，而不能使用 Hash 路由，所以對於沒有做預渲染的頁面往往需要伺服器配置路由，如nginx 配置如下：

3、對於動態路由，如 /detail/:id ，是不支持的，不過可以換成 query 路由，如 /detail?id=

4、應用場景比較有限，能想到的就是骨架屏應用，比如首頁，為了速度，我們會用一些骨架屏組件，如果不做預渲染，則骨架屏組件會等整個js文件載入完畢才開始渲染，體驗不好。如果做了預渲染，則當html文件載入完畢時就會開始渲染了