2020年12月21日，圣誕節前夕，React團隊發了關于React Server Components的博客和RFC，一方面是公布他們關于React的進展，另一方面是希望吸取業界的反饋，
本文解答：什么是React Server Components？有什么亮點？

前端簡史

• 【靜態】在最早的時候是根本沒有前端或者后端的概念的，當時就是用 Dreamweaver 寫 html 靜態頁面，然后部署到一臺電腦的 IIS (Internet Information Services) 上，當請求這個頁面時，回傳這個 html 檔案，
• 【模版】再后面一點，服務端變得復雜了一些，html 頁面開始使用各種模板來寫，譬如 Java 系列的 FreeMarker，還有 ASP 、 PHP 等等，此時，前后端開發是一體的，最多也就是模板的撰寫算是最初的前端范疇，但那個時候，這個活兒往往都是現在的后端開發去干的，
• 【Web2.0】隨著 2005年 Ajax (Asynchronous JavaScript and XML) 的誕生，徹底得改變了這一切，JS 腳本可以獨立向服務器請求資料，拿到資料后，進行處理并更新網頁，這個程序中，后端只負責提供資料，其他事情都由前端來做，不夸張的說，這一年算得上是 Web 開發技術發展的元年，Web也從 1.0 的時代，步入 2.0 的時代，促進了前后端的分離，
• 【MVC】前端可以通過 Ajax 獲取資料，因此也就有了處理資料的需求，于是就促使了前端 MVC 的誕生，在這個階段的后期，前端逐漸開始有了一點工程化的影子，并且開始受 CommonJS 的影響，有了模塊化編程的概念，誕生了相應的 CMD 和 AMD 的規范，開始有了構建工具 Grunt/Gulp，開始有了編碼的規范 JsLint，
• 【MVVM】MVVM 同樣是一種軟體架構模式，它是在 MVC 的基礎上演進過來的，去掉了 MVC 中的 Controller，增加了資料的雙向系結，最有代表性的框架就是 Google 公司推出的 Angular， 它的風格屬于 HTML 語言的增強，核心概念就是資料雙向系結，
• 【SPA】用戶第一次發起頁面請求時，后端回傳HTML、 CSS 和 JS檔案，JS 檔案包括了頁面切換邏輯的處理，這是單頁應用實作的關鍵，它利用 Hash 或者 History 的技術，實作了當切換頁面時，首先通過 Ajax 獲取到新頁面需要的資料，然后由 JS 根據要切換到的網址，使用獲取到的資料來拼接出要展示頁面的 HTML，整個切換頁面的動作全部由前端來完成了，這就是單頁應用，所有的資源只在第一次頁面請求時被加載，后面都只會發起 Ajax 請求獲取資料而已，
• 【SSR】SPA 讓 web 變成了應用的形態，它是客戶端渲染（client side render），客戶端渲染有它的弊端，譬如沒法做 SEO(Search Engine Optimization)，由于所有的 JS 和 CSS會在首次訪問時被全部加載，并且 HTML 是在前端組裝的，就勢必導致首屏加載以及渲染的時間會增加，影響用戶體驗（不過有了代碼分割，只要不需要SEO，SPA現在依然是最流行的方案），目前NextJS是個不錯的SSR框架，此外umi也支持SSR，也支持SSR失敗時自動降級為CSR，

背景

Good & Cheap & Fast

Dan在視頻開頭，提到了Project Management中的概念：一個專案中，Good、Cheap、Fast三種屬性很難同時具備，通常只能追求其二的極致，這同樣適用于React開發：好的用戶體驗、低成本的代碼維護、快的性能，

舉個例子：一個典型的展示組件的例子，
給一個作曲家id，渲染他的詳情頁，里面可以看到他的TopTracks，Discography，當然，TopTracks和Discography不一定非要在詳情頁可以看到（其他地方也可以參考，希望它是公共的，不是詳情頁私有的組件）

好的用戶體驗、快的性能

如果能夠在父組件統一獲取資料，再傳遞資料給子組件，那么性能是快的，避免了多個API請求，用戶體驗也好，但是維護成本又高，每個資料需要一層一層傳遞下去，如果API做了改動，每個子組件都要改；此外要復用TopTracks和Discography的話，就需要在其它地方重新寫獲取資料的邏輯，

快的性能、低成本的代碼維護

如果我們只允許用戶在詳情頁能看到TopTracks和Discography，這樣這倆組件不必是公用組件，我們可以以低成本、快性能的渲染他們，但是用戶必須進入詳情頁才能看到這些組件，用戶體驗不好，

低成本的代碼維護、好的用戶體驗

我們把每個資料獲取邏輯放在各個組件內，維護起來很方便，用戶體驗也不錯，但是性能差，發送了3個請求，而且這些請求是「瀑布流」：
先渲染ArtistDetails，等它拿到資料后，才會繼續渲染children，children才會開始獲取資料，

這只是前端專案中一個例子，但其實很常見，（只是他們產生的原因可能不同，很多專案中產生的原因是后者請求的API依賴于前者的結果，上面例子只是單純因為渲染的順序導致了瀑布流）

已有的解決方案

已有的問題，主要是Client和Server之間來回的資料獲取邏輯，一來一回，再來再回，形成了瀑布流，損耗了很多時間，
GraphQL通過一次性請求資料，拿到了所有，解決了這個問題，
GraphQL + Relay （React中用于GraphQL獲取資料的庫）
這在Facebook內部帶來了很多益處，但是難以推廣普及：

• GraphQL并不普遍，不是所有人都會用
• 已有的龐大專案改造為GraphQL成本太高（“明明是解決的前端痛點，卻非要改造后端”）
• 不是所有人都喜歡它

新的解決方案

而React團隊提出的新的解決方案，則是這樣的：

Client發送請求，Server直接渲染組件，并在Server本地獲取資料，不管瀑布有多長，都可以很快的拿到所有資料，然后在Server渲染出組件，一次性回傳給Client，
在Server端運行的React Component就是React Server Component，
在過去，前端都是Client Component：

現在，引入Server Component后，組件樹可能會是這樣：

怎么用React Server Component？

參考demo：https://github.com/reactjs/server-components-demo

獲取資料

NoteList.server.js

import {fetch} from 'react-fetch';

export default function NoteList({searchText}) {
  const notes = fetch('http://localhost:4000/notes').json();

  return notes.length > 0 ? (
    <ul className="notes-list">
      {notes.map((note) => (
        <li key={note.id}>
          <SidebarNote note={note} />
        </li>
      ))}
    </ul>
  ) : (
    <div className="notes-empty">
      {searchText
        ? `Couldn't find any notes titled "${searchText}".`
        : 'No notes created yet!'}{' '}
    </div>
  );
}

Server Component里可以直接獲取資料（不需要像Client Component一樣，要在useEffect中執行），而且它還可以操作本地檔案、甚至可以直接執行資料庫查詢陳述句，Server Component在Server執行，后端能做的，它基本都可以做到，

參考其它組件

Server Component里可以參考Client Component，以指令的形式回傳給Client，
Server Component會將組件及其從IO請求到的資料序列化為特定的資料結構（稱之為指令），以流的形式傳遞給前端：

客戶端在運行時直接獲取到填充了資料的流，并借助Concurrent Mode執行流式渲染，
指令含義：

• M：下載Client組件，收到后會立即下載該模塊
• J：序列化的Server組件，收到后該組件可以直接渲染
• S：Symbol，suspense是其中一種

服務端組件的依賴，不會被打包

Note.server.js中，參考了date-fns，但是在瀏覽器Sources中看不到這個資源，而且Server Component全都不在里面，
Amazing!

約束

Server Component不能有狀態、事件監聽器，如果需要互動，只能使用Client Component，（見SidebarNote.js，它把“資料”（其實是JSX）傳遞給了Client Component，由Client Component控制不同狀態的顯示內容）
Server Component不能傳遞函式引數給Client Component，因為函式無法被序列化，而JSX可序列化，所以也能傳遞JSX，
如果傳遞的JSX也是Server Component，那么它會在Server先渲染完畢，再發送給Client，（這意味著這部分Server Component也不會被Client下載）

混用的同時，保持Client Component的狀態

左側串列是個Server Component，參考的Client Component保存了展開/收起的狀態，如果你新增、洗掉一個專案，他們展開/收起的狀態會被保持！
Amazing!
這在CSR時代，是需要花一定成本才能實作的功能，在Server Component中，re-render直接可以保持Client Component的狀態，非常優秀！

Shared Component組件

有的組件以.js結尾，而非.server.js或.client.js，則它既可以在Server渲染，又可以在Client渲染，
如果Server Component里用到了Shared Component或Server Component，那么將會在Server渲染后，以指令的形式回傳給Client，他們不會被下載到Client，
如果Client Component里用到了Shared Component或Client Component，那么會在瀏覽器渲染，他們會被下載到Client，
如果Client Component里用到了Server Component，會發送請求，
Amazing!
很多系統是區分多角色的，不同角色應該看到不同的內容，這樣組件級別的按需加載，正是我們想要的！

這在當前，是非常常見的React代碼模式，但是把它切換為Server Component后，無編輯權限的人，不會下載EditToolbar組件，（CSR模式只能做到下載但不顯示）

修改+更新，只觸發1次請求

CSR時代，我們通常先呼叫API去修改資料，才重新get新的資料，但是使用Server Component后，我們只需要1次請求，就可以完成這件事！
Amazing!

React IO

React鼓勵社區去開發維護這些IO庫，可用于Server Components，但這不意味著重新造輪子，他們只是針對已有的node庫做了一層很薄的封裝，例如react-fs只封裝了fs，react-fetch只封裝了fetch，都不到一百行，封裝成React IO庫只是增加了快取層，

關于慢請求

結合Suspense，以流的形式渲染，開發成本低，效果好！

會取代GraphQL嗎

不會，他們可以協作，

優勢

解決瀑布流問題

0打包體積

假設我們開發一款MD編輯器，服務端傳遞給前端MD格式的字串，
我們需要在前端引入將MD決議為HTML字串的庫，這個庫就有206k，
import marked from ‘marked’; // 35.9K (11.2K gzipped)
import sanitizeHtml from ‘sanitize-html’; // 206K (63.3K gzipped)

function NoteWithMarkdown({text}) {
const html = sanitizeHtml(marked(text));
return (/* render */);
}

通過ServerComponent我們怎么解決這個問題呢？
只需要簡單將NoteWithMarkdown標記為ServerComponent，將引入并決議MD這部分邏輯放在服務端執行，
ServerComponent并不會增加前端專案打包體積，這個例子中，一次性為我們減少了前端206K (63.3K gzipped)的打包體積以及決議MD的時間，

自動代碼分割

通過使用React.lazy可以實作組件的動態import，之前，這需要我們在切換組件/路由時手動執行，在ServerComponent中，都是自動完成的，

在上圖中，左側串列是ServerComponent，當點擊其中卡片時，組件對應資料會動態加載，

與相關技術的對比

SSR

Server Components 跟過去的 SSR 相比，你在拉取后不會丟失客戶端的狀態；
SSR 首次訪問時回傳渲染完的頁面，Server Components 輸出的是一系列指令，
Server Components可以通過分塊加載、減少打包體積等方式，進一步提升加載速度，
注：二者是不同的技術方案，解決的問題不同，但可以混用，SSR主要解決的問題是SEO和首屏渲染速度，

PHP等后端框架

在 PHP/ASP 時代，頁面都是由服務器來渲染，服務器接到請求后，查詢資料庫然后把資料“塞”到頁面里面，最后把生成好的 html 發送給客戶端，當用戶點擊鏈接后，繼續重復上面的步驟，這樣用戶體驗不是很好，每個操作幾乎都要重繪頁面，服務器處理完之后再回傳新的頁面，

SPA

而 Angular/Vue/React 這種單頁應用(SPA)則主要是客戶端渲染，服務器接到請求后，把 index.html 以及 js/css/img 等發送給瀏覽器，瀏覽器負責渲染整個頁面，后續用戶操作和前面的 php/jquery 一樣，通過 ajax 和后端互動，但是和 php 相比，第一次訪問時只回傳了什么內容都沒有的 idnex.html 空頁面，沒法做 SEO，另一點就是頁面需要等到 js/css 和介面都回傳之后才能顯示出來，首次訪問會有白屏，

推薦閱讀

https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html
https://github.com/reactjs/rfcs/pull/188