為什麼要實現服務端渲染(SSR)
總結下來有以下幾點：
- SEO，讓搜尋引擎更容易讀取頁面內容
- 首屏渲染速度更快（重點），無需等待js檔案下載執行的過程
- 程式碼同構，服務端和客戶端可以共享某些程式碼
今天我們將構建一個使用Redux的簡單的React應用程式，實現服務端渲染(SSR)。該示例包括非同步資料抓取，這使得任務變得更有趣。
如果您想使用本文中討論的程式碼，請檢視GitHub: answer518/react-redux-ssr
安裝環境
在開始編寫應用之前，需要我們先把環境編譯/打包環境配置好，因為我們採用的是es6語法編寫程式碼。我們需要將程式碼編譯成es5程式碼在瀏覽器或node環境中執行。
我們將用babelify轉換來使用browserify和watchify來打包我們的客戶端程式碼。對於我們的伺服器端程式碼，我們將直接使用babel-cli。
程式碼結構如下:
|
1 2 3 4 5 6 7 |
build src ├── client │ └── client.js └── server └── server.js |
我們在package.json裡面加入以下兩個命令指令碼:
|
1 2 3 4 5 6 7 8 9 10 11 |
"scripts": { "build": " browserify ./src/client/client.js -o ./build/bundle.js -t babelify && babel ./src/ --out-dir ./build/", "watch": " concurrently "watchify ./src/client/client.js -o ./build/bundle.js -t babelify -v" "babel ./src/ --out-dir ./build/ --watch" " } |
concurrently庫幫助並行執行多個程式，這正是我們在監控更改時需要的。
最後一個有用的命令，用於執行我們的http伺服器:
|
1 2 3 4 5 6 |
"scripts": { "build": "...", "watch": "...", "start": "nodemon ./build/server/server.js" } |
不使用node ./build/server/server.js而使用Nodemon的原因是，它可以監控我們程式碼中的任何更改，並自動重新啟動伺服器。這一點在開發過程會非常有用。
開發React+Redux應用
假設服務端返回以下的資料格式：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
[ { "id": 4, "first_name": "Gates", "last_name": "Bill", "avatar": "https://s3.amazonaws.com/uifaces/faces/twitter/marcoramires/128.jpg" }, { ... } ] |
我們通過一個元件將資料渲染出來。在這個元件的componentWillMount生命週期方法中，我們將觸發資料獲取，一旦請求成功，我們將傳送一個型別為user_fetch的操作。該操作將由一個reducer處理，我們將在Redux儲存中獲得更新。狀態的改變將觸發我們的元件重新呈現指定的資料。
Redux具體實現
reducer處理過程如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
// reducer.js import { USERS_FETCHED } from './constants'; function getInitialState() { return { users: null }; } const reducer = function (oldState = getInitialState(), action) { if (action.type === USERS_FETCHED) { return { users: action.response.data }; } return oldState; }; |
為了能派發action請求去改變應用狀態，我們需要編寫Action Creator：
|
1 2 3 4 5 6 7 |
// actions.js import { USERS_FETCHED } from './constants'; export const usersFetched = response => ({ type: USERS_FETCHED, response }); // selectors.js export const getUsers = ({ users }) => users; |
Redux實現的最關鍵一步就是建立Store:
|
1 2 3 4 5 6 7 |
// store.js import { USERS_FETCHED } from './constants'; import { createStore } from 'redux'; import reducer from './reducer'; export default () => createStore(reducer); |
為什麼直接返回的是工廠函式而不是
createStore(reducer)?這是因為當我們在伺服器端渲染時，我們需要一個全新的Store例項來處理每個請求。
實現React元件
在這裡需要提的一個重點是，一旦我們想實現服務端渲染，那我們就需要改變之前的純客戶端程式設計模式。
伺服器端渲染，也叫程式碼同構，也就是同一份程式碼既能在客戶端渲染，又能在服務端渲染。
我們必須保證程式碼能在服務端正常的執行。例如，訪問Window物件，Node不提供Window物件的訪問。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
// App.jsx import React from 'react'; import { connect } from 'react-redux'; import { getUsers } from './redux/selectors'; import { usersFetched } from './redux/actions'; const ENDPOINT = 'http://localhost:3000/users_fake_data.json'; class App extends React.Component { componentWillMount() { fetchUsers(); } render() { const { users } = this.props; return ( <div> { users && users.length > 0 && users.map( // ... render the user here ) } </div> ); } } const ConnectedApp = connect( state => ({ users: getUsers(state) }), dispatch => ({ fetchUsers: async () => dispatch( usersFetched(await (await fetch(ENDPOINT)).json()) ) }) )(App); export default ConnectedApp; |
你看到，我們使用componentWillMount來傳送fetchUsers請求，componentDidMount為什麼不能用呢？ 主要原因是componentDidMount在服務端渲染過程中並不會執行。
fetchUsers是一個非同步函式，它通過Fetch API請求資料。當資料返回時，會派發users_fetch動作，從而通過reducer重新計算狀態，而我們的<App />由於連線到Redux從而被重新渲染。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
// client.js import React from 'react'; import ReactDOM from 'react-dom'; import { Provider } from 'react-redux'; import App from './App.jsx'; import createStore from './redux/store'; ReactDOM.render( <Provider store={ createStore() }><App /></Provider>, document.querySelector('#content') ); |
執行Node Server
為了演示方便，我們首選Express作為http伺服器。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
// server.js import express from 'express'; const app = express(); // Serving the content of the "build" folder. Remember that // after the transpiling and bundling we have: // // build // ├── client // ├── server // │ └── server.js // └── bundle.js app.use(express.static(__dirname + '/../')); app.get('*', (req, res) => { res.set('Content-Type', 'text/html'); res.send(` <html> <head> <title>App</title> </head> <body> <div id="content"></div> <script src="/bundle.js"></script> </body> </html> `); }); app.listen( 3000, () => console.log('Example app listening on port 3000!') ); |
有了這個檔案，我們可以執行npm run start並訪問http://localhost:3000。我們看到資料獲取成功，併成功的顯示了。
服務端渲染
目前為止，我們的服務端僅僅是返回了一個html骨架，而所有互動全在客戶端完成。瀏覽器需要先下載bundle.js後執行。而服務端渲染的作用就是在伺服器上執行所有操作併傳送最終標記，而不是把所有工作交給瀏覽器執行。React足夠的聰明，能夠識別出這些標記。
還記得我們在客戶端做的以下事情嗎?
|
1 2 3 4 5 6 |
import ReactDOM from 'react-dom'; ReactDOM.render( <Provider store={ createStore() }><App /></Provider>, document.querySelector('#content') ); |
服務端幾乎相同：
|
1 2 3 4 5 |
import ReactDOMServer from 'react-dom/server'; const markupAsString = ReactDOMServer.renderToString( <Provider store={ store }><App /></Provider> ); |
我們使用了相同的元件<App />和 store，不同之處在於它返回的是一個字串，而不是虛擬DOM。
然後將這個字串加入到Express的響應裡面，所以服務端程式碼為：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
const store = createStore(); const content = ReactDOMServer.renderToString( <Provider store={ store }><App /></Provider> ); app.get('*', (req, res) => { res.set('Content-Type', 'text/html'); res.send(` <html> <head> <title>App</title> </head> <body> <div id="content">${ content }</div> <script src="/bundle.js"></script> </body> </html> `); }); |
如果重新啟動伺服器並開啟相同的http://localhost:3000，我們將看到以下響應:
|
1 2 3 4 5 6 7 8 9 |
<html> <head> <title>App</title> </head> <body> <div id="content"><div data-reactroot=""></div></div> <script src="/bundle.js"></script> </body> </html> |
我們的頁面中確實有一些內容，但它只是<div data-reactroot=””></div>。這並不意味著程式出錯了。這絕對是正確的。React確實呈現了我們的頁面，但它只呈現靜態內容。在我們的元件中，我們在獲取資料之前什麼都沒有，資料的獲取是一個非同步過程，在伺服器上呈現時，我們必須考慮到這一點。這就是我們的任務變得棘手的地方。這可以歸結為我們的應用程式在做什麼。在本例中，客戶端程式碼依賴於一個特定的請求，但如果使用redux-saga庫，則可能是多個請求，或者可能是一個完整的root saga。我意識到處理這個問題的兩種方法:
1、我們明確知道請求的頁面需要什麼樣的資料。我們獲取資料並使用該資料建立Redux儲存。然後我們通過提供已完成的Store來呈現頁面，理論上我們可以做到。
2、我們完全依賴於執行在客戶端上的程式碼，計算出最終的結果。
第一種方法，需要我們在兩端做好狀態管理。第二種方法需要我們在服務端使用一些額外的庫或工具，來確保同一套程式碼能在服務端和客戶端做相同的事情，我個人比較推薦使用這種方法。
例如，我們使用了Fetch API向後端發出非同步請求，而服務端預設是不支援的。我們需要做的就是在server.js中將Fetch匯入:
|
1 2 |
import 'isomorphic-fetch'; |
我們使用客戶端API接收非同步資料，一旦Store獲取到非同步資料，我們將觸發ReactDOMServer.renderToString。它會提供給我們想要的標記。我們的Express處理器是這樣的:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
app.get('*', (req, res) => { const store = createStore(); const unsubscribe = store.subscribe(() => { const users = getUsers(store.getState()); if (users !== null && users.length > 0) { unsubscribe(); const content = ReactDOMServer.renderToString( <Provider store={ store }><App /></Provider> ); res.set('Content-Type', 'text/html'); res.send(` <html> <head> <title>App</title> </head> <body> <div id="content">${ content }</div> <script src="/bundle.js"></script> </body> </html> `); } }); ReactDOMServer.renderToString(<Provider store={ store }><App /></Provider>); }); |
我們使用Store的subscribe方法來監聽狀態。當狀態發生變化——是否有任何使用者資料被獲取。如果users存在，我們將unsubscribe()，這樣我們就不會讓相同的程式碼執行兩次，並且我們使用相同的儲存例項轉換為string。最後，我們將標記輸出到瀏覽器。
store.subscribe方法返回一個函式，呼叫這個函式就可以解除監聽
有了上面的程式碼，我們的元件已經可以成功地在伺服器端渲染。通過開發者工具，我們可以看到傳送到瀏覽器的內容：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
<html> <head> <title>App</title> <style> body { font-size: 18px; font-family: Verdana; } </style> </head> <body> <div id="content"><div data-reactroot=""><p>Eve Holt</p><p>Charles Morris</p><p>Tracey Ramos</p></div></div> <script> window.__APP_STATE = {"users":[{"id":4,"first_name":"Eve","last_name":"Holt","avatar":"https://s3.amazonaws.com/uifaces/faces/twitter/marcoramires/128.jpg"},{"id":5,"first_name":"Charles","last_name":"Morris","avatar":"https://s3.amazonaws.com/uifaces/faces/twitter/stephenmoon/128.jpg"},{"id":6,"first_name":"Tracey","last_name":"Ramos","avatar":"https://s3.amazonaws.com/uifaces/faces/twitter/bigmancho/128.jpg"}]}; </script> <script src="/bundle.js"></script> </body> </html> |
當然，現在並沒有結束，客戶端JavaScript不知道伺服器上發生了什麼，也不知道我們已經對API進行了請求。我們必須通過傳遞Store的狀態來通知瀏覽器，以便它能夠接收它。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
const content = ReactDOMServer.renderToString( <Provider store={ store }><App /></Provider> ); res.set('Content-Type', 'text/html'); res.send(` <html> <head> <title>App</title> </head> <body> <div id="content">${ content }</div> <script> window.__APP_STATE = ${ JSON.stringify(store.getState()) }; </script> <script src="/bundle.js"></script> </body> </html> `); |
我們將Store狀態放到一個全域性變數__APP_STATE中，reducer也有一點變化：
|
1 2 3 4 5 6 7 |
function getInitialState() { if (typeof window !== 'undefined' && window.__APP_STATE) { return window.__APP_STATE; } return { users: null }; } |
注意typeof window !== 'undefined',我們必須這樣做，因為這段程式碼也會在服務端執行，這就是為什麼說在做服務端渲染時要非常小心，尤其是全域性使用的瀏覽器api的時候。
最後一個需要優化的地方，就是當已經取到users時，必須阻止fetch。
|
1 2 3 4 5 6 7 8 |
componentWillMount() { const { users, fetchUsers } = this.props; if (users === null) { fetchUsers(); } } |
總結
伺服器端呈現是一個有趣的話題。它有很多優勢，並改善了整體使用者體驗。它還會提升你的單頁應用程式的SEO。但這一切並不簡單。在大多數情況下，需要額外的工具和精心選擇的api。
這只是一個簡單的案例，實際開發場景往往比這個複雜的多，需要考慮的情況也會非常多，你們的服務端渲染是怎麼做的？