免费av在线久草,亚洲熟伦熟女新五十路熟妇,青青草原免费体验视频

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

ReactServerComponent從理念到原理

大家好，我卡頌。

React Server Component（后文簡稱RSC）是React近幾年最重要的特性。雖然他對React未來發(fā)展至關(guān)重要，但由于：

仍屬實驗特性。
配置比較繁瑣，且局限較多。

所以雖然體驗Demo[1]已經(jīng)發(fā)布3年了，但仍屬于「知道的人多，用過的人少」。

本文會從以下幾個角度介紹RSC：

RSC是用來做啥的？
RSC和其他服務(wù)端渲染方案（SSR、SSG）的區(qū)別
RSC的工作原理

希望讀者讀完本文后對RSC的應(yīng)用場景有清晰的認識。

本文參考了how-react-server-components-work[2]

什么是RSC

對于一個React組件，可能包含兩種類型的狀態(tài)：

前端交互用的狀態(tài)，比如加載按鈕的顯/隱狀態(tài)
后端請求回的數(shù)據(jù)，比如下面代碼中的data狀態(tài)用于保存后端數(shù)據(jù)：

function App() {
  const [data, update] = useState(null);
  
  useEffect(() => {
    fetch(url).then(res => update(res.json()))
  }, [])
  
  return ;
}

「前端交互用的狀態(tài)」放在前端很合適，但「后端請求回的數(shù)據(jù)」邏輯鏈路如果放在前端則比較繁瑣，整個鏈路類似如下：

前端請求并加載React業(yè)務(wù)邏輯代碼。
應(yīng)用執(zhí)行渲染流程。
App組件mount，執(zhí)行useEffect，請求后端數(shù)據(jù)。
后端數(shù)據(jù)返回，App組件的子組件消費數(shù)據(jù)。

如果我們根據(jù)「狀態(tài)類型」將組件分類，比如：

「只包含交互相關(guān)狀態(tài)」的組件，叫客戶端組件（React Client Component，簡寫RCC）。
「只從數(shù)據(jù)源獲取數(shù)據(jù)」的組件，叫服務(wù)端組件（React Server Component，簡寫RSC）。

按照這種邏輯劃分，上述代碼中：

App組件只包含數(shù)據(jù)，顯然屬于SSR。
App組件的子組件Ctn消費data，如果他內(nèi)部包含交互邏輯，應(yīng)該屬于RCC。

將上述代碼改寫為：

function App() {
  // 從數(shù)據(jù)庫獲取數(shù)據(jù)
  const data = getDataFromDB();
  return ;
}

其中：

App組件在后端運行，可以直接從數(shù)據(jù)源（這里是數(shù)據(jù)庫）獲取數(shù)據(jù)
Ctn組件在前端運行，消費數(shù)據(jù)

改造后「前端交互用的狀態(tài)」邏輯鏈路不變，而「后端請求回的數(shù)據(jù)」邏輯鏈路卻變短很多：

后端從數(shù)據(jù)源獲取數(shù)據(jù)，將RSC數(shù)據(jù)返回給前端。
前端請求并加載業(yè)務(wù)邏輯代碼（來自步驟0）。
應(yīng)用執(zhí)行渲染流程（此時App組件已經(jīng)包含數(shù)據(jù)）。
App組件的子組件消費數(shù)據(jù)。

這就是RSC的理念，一句話概括就是 —— 根據(jù)狀態(tài)類型，劃分組件類型，RCC在前端運行，RSC在后端運行。

與SSR、SSG的區(qū)別

同樣涉及到前端框架的后端運行，RSC與SSR、SSG有什么區(qū)別呢？

首先，SSG是后端「編譯時方案」。使用SSG的業(yè)務(wù)，后端代碼在編譯時會生成HTML（通常會被上傳CDN）。當前端發(fā)起請求后，后端（或CDN）始終會返回編譯生成的HTML。

RSC與SSR則都是后端「運行時方案」。也就是說，他們都是前端發(fā)起請求后，后端對請求的實時響應(yīng)。根據(jù)請求參數(shù)不同，可以作出不同響應(yīng)。

同為后端運行時方案，RSC與SSR的區(qū)別主要體現(xiàn)在輸出產(chǎn)物：

類似于SSG，SSR的輸出產(chǎn)物是HTML，瀏覽器可以直接解析。
RSC會流式輸出一種「類JSON」的數(shù)據(jù)結(jié)構(gòu)，由前端的React相關(guān)插件解析。

既然輸出產(chǎn)物不同，那么他們的應(yīng)用場景也是不同的。

比如，在需要考慮SEO（即需要后端直接輸出HTML）時，SSR與SSG可以勝任（都是輸出HTML），而RSC則不行（流式輸出）。

同時，由于實現(xiàn)不同，同一個應(yīng)用中可以同時存在SSG、SSR以及RSC。

RSC的限制

「RSC規(guī)范」是如何區(qū)分RSC與RCC的呢？根據(jù)規(guī)范定義：

帶有.server.js(x)后綴的文件導(dǎo)出的是RSC。
帶有.client.js(x)后綴的文件導(dǎo)出的是RCC。
沒有帶server或client后綴的文件導(dǎo)出的是通用組件。

所以，我們上述例子可以導(dǎo)出為2個文件：

// app.server.jsx
function App() {
  // 從數(shù)據(jù)庫獲取數(shù)據(jù)
  const data = getDataFromDB();
  return ;
}

// ctn.client.jsx
function Ctn({data}) {
  // ...省略邏輯
}

對于任意應(yīng)用，按照「RSC規(guī)范」拆分組件后，能得到類似如下的組件樹，其中RSC和RCC可能交替出現(xiàn)：

但是需要注意：RCC中是不允許import RSC的。也就是說，如下寫法是不支持的：

// ClientCpn.client.jsx

import ServerCpn from './ServerCpn.server'
export default function ClientCpn() {
  return (
    
      
    
  )
}

這是因為，如果一個組件是RCC，他運行的環(huán)境就是前端，那么他的子孫組件的運行環(huán)境也是前端，但RSC是需要在后端運行的。

那么上述RSC和RCC交替出現(xiàn)是如何實現(xiàn)的呢？

答案是：通過children。

改寫下ClientCpn.client.jsx：

// ClientCpn.client.jsx

export default function ClientCpn({children}) {
  return (
    {children}
  )
}

在OuterServerCpn.server.jsx中引入ClientCpn與ServerCpn：

// OuterServerCpn.server.jsx
import ClientCpn from './ClientCpn.client'
import ServerCpn from './ServerCpn.server'
export default function OuterServerCpn() {
  return (
    
      
    
  )
}

組件結(jié)構(gòu)如下：

解釋下這段代碼，首先OuterServerCpn是RSC，則他運行的環(huán)境是后端。他引入的ServerCpn組件運行環(huán)境也是后端。

ClientCpn組件雖然運行環(huán)境在前端，但是等他運行時，他拿到的children props是后端已經(jīng)執(zhí)行完邏輯（已經(jīng)獲得數(shù)據(jù)）的ServerCpn組件。

RSC協(xié)議詳解

我們可以將RSC看作一種rpc（Remote Procedure Call，遠程過程調(diào)用）協(xié)議的實現(xiàn)。數(shù)據(jù)傳輸?shù)膬啥朔謩e是「React后端運行時」與「React前端運行時」。

一款rpc協(xié)議最基本的組成包括三部分：

數(shù)據(jù)的序列化與反序列化
id映射
傳輸協(xié)議

以上面的OuterServerCpn.server.jsx舉例：

// OuterServerCpn.server.jsx
import ClientCpn from './ClientCpn.client'
import ServerCpn from './ServerCpn.server'
export default function OuterServerCpn() {
  return (
    
      
    
  )
}

// ClientCpn.client.jsx
export default function({children}) {
  return {children};
}

// ServerCpn.server.jsx
export default function() {
  return 服務(wù)端組件;
}

這段組件代碼轉(zhuǎn)化為RSC數(shù)據(jù)后如下（不用在意數(shù)據(jù)細節(jié)，后文會解釋）：

M1:{"id":"./src/ClientCpn.client.js","chunks":["client1"],"name":""}
J0:["$","div",null,{"className":"main","children":["$","@1",null,{"children":["$","div",null,{"children":"服務(wù)端組件"}]}]}]

接下來我們從上述三個角度分析這段數(shù)據(jù)結(jié)構(gòu)的含義。

數(shù)據(jù)的序列化與反序列化

RSC是一種「按行分隔」的數(shù)據(jù)結(jié)構(gòu)（方便按行流式傳輸），每行的格式為：

[標記][id]: JSON數(shù)據(jù)

其中：

「標記」代表這行的數(shù)據(jù)類型，比如J代表「組件樹」，M代表「一個RCC的引用」，S代表Suspense
id代表這行數(shù)據(jù)對應(yīng)的id。
JSON數(shù)據(jù)保存了這行具體的數(shù)據(jù)。

RSC的序列化與反序列化其實就是JSON的序列化與反序列化。反序列化后的數(shù)據(jù)再根據(jù)「標記」不同做不同處理。

比如，對于上述代碼中第二行數(shù)據(jù)：

J0:["$","div",null,{"className":"main","children":["$","@1",null,{"children":["$","div",null,{"children":"服務(wù)端組件"}]}]}]

可以理解為，這行數(shù)據(jù)描述了一棵組件樹（標記J），id為0，組件樹對應(yīng)數(shù)據(jù)為：

[
  "$","div",null,{
    "className":"main","children":[
      "$","@1",null,{
        "children":["$","div",null,{
          "children":"服務(wù)端組件"}]
        }
      ]
    }
]

當前端反序列化這行數(shù)據(jù)后，會根據(jù)上述JSON數(shù)據(jù)渲染組件樹。

id映射

所謂「id映射」，是指對于同一個數(shù)據(jù)，如何在rpc協(xié)議傳輸?shù)膬啥藢?yīng)上？

在「RSC協(xié)議」的語境下，是指對于同一個組件，經(jīng)由RSC在React前后端運行時之間傳遞，是如何對應(yīng)上的。

還是考慮上面的例子，回顧下第二行RSC對應(yīng)的數(shù)據(jù)：

[
  "$","div",null,{
    "className":"main","children":[
      "$","@1",null,{
        "children":["$","div",null,{
          "children":"服務(wù)端組件"}]
        }
      ]
    }
]

這段數(shù)據(jù)結(jié)構(gòu)有些類似JSX的返回值，把他與組件層級放到一張圖里對比下：

可以發(fā)現(xiàn)，這些信息已經(jīng)足夠前端渲染、組件了，但是對應(yīng)的數(shù)據(jù)@1是什么意思呢？

這需要結(jié)合第一行RSC的數(shù)據(jù)來分析：

M1:{"id":"./src/ClientCpn.client.js","chunks":["client1"],"name":""}

M標記代表這行數(shù)據(jù)是「一個RCC的引用」，id為1，數(shù)據(jù)為：

{
  "id":"./src/ClientCpn.client.js",
  "chunks":["client1"],
  "name":""
}

第二行中的@1就是指「引用id為1的RCC」，根據(jù)第一行RSC提供的信息，React前端運行時知道id為1的RCC包含一個名為client1的chunk，路徑為"./src/ClientCpn.client.js"。

于是React前端運行時會向這個路徑發(fā)起JSONP請求，請求回組件對應(yīng)代碼：

如果應(yīng)用包裹了，那么請求過程中會顯示fallback效果。

可以看到，通過協(xié)議中的：

M[id]，定義id對應(yīng)的「RCC數(shù)據(jù)」。
@[id]，引用id對應(yīng)的「RCC數(shù)據(jù)」。

就能將同一個RCC在React前后端運行時對應(yīng)上。

那么，為什么RCC不像RSC一樣直接返回數(shù)據(jù)，而是返回引用id呢？

主要是因為RCC中可能包含前端交互邏輯，而有些邏輯是不能通過「RSC協(xié)議」序列化的（底層是JSON序列化）。

比如下面的onClick props是一個函數(shù)，函數(shù)是不能通過JSON序列化的：

這里我們再梳理下「RSC協(xié)議」中「id映射」的完整過程：

業(yè)務(wù)開發(fā)時通過.server ｜ client后綴區(qū)分組件類型。
后端代碼編譯時，所有RCC（即.client后綴文件）會編譯出獨立文件（這一步是react-server-dom-webpack[3]插件做的，對于Vite，也有人提了Vite插件的實現(xiàn) PR[4]）。
React后端返回給前端的RSC數(shù)據(jù)中包含了組件樹（J標記）等按行表示的數(shù)據(jù)。
React前端根據(jù)J標記對應(yīng)數(shù)據(jù)渲染組件樹，遇到「引用RCC」（形如M[id]）時，根據(jù)id發(fā)起JSONP請求。
請求返回該RCC對應(yīng)組件代碼，請求過程的pending狀態(tài)由展示。

傳輸協(xié)議

RSC數(shù)據(jù)是以什么格式在前后端間傳遞呢？

不同于一些rpc協(xié)議會基于TCP或UDP實現(xiàn)，「RSC協(xié)議」直接基于「HTTP協(xié)議」實現(xiàn)，其Content-Type為text/x-component。

總結(jié)

本文從理念、原理角度講解了RSC，過程中回答了幾個問題。

Q：RSC和其他服務(wù)端渲染方案有什么區(qū)別？

A：RSC是服務(wù)端運行時的方案，采用流式傳輸。

Q：為什么需要區(qū)分RSC與RCC（通過文件后綴）？

A：因為RSC需要在后端獲取數(shù)據(jù)后流式傳輸給前端，而RCC在后端編譯時編譯成獨立文件，前端渲染時再以JSONP的形式請求該文件

Q：為什么RCC中不能import RSC？

A：因為他們的運行環(huán)境不同（前者在前端，后者在后端）

由于配置繁瑣，并不推薦在現(xiàn)有React項目中使用RSC。想體驗RSC的同學，可以使用Next.js并開啟App Router：

在這種情況下，組件默認為RSC。

參考資料

[1]體驗Demo:https://github.com/reactjs/server-components-demo

[2]how-react-server-components-work:https://www.plasmic.app/blog/how-react-server-components-work

[3]react-server-dom-webpack:https://www.npmjs.com/package/react-server-dom-webpack

[4]Vite插件的實現(xiàn) PR:https://github.com/facebook/react/pull/26926

當前文章：ReactServerComponent從理念到原理
標題路徑：http://www.dlmjj.cn/article/dpocsie.html

日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

新聞中心

什么是RSC

與SSR、SSG的區(qū)別

RSC的限制

RSC協(xié)議詳解

數(shù)據(jù)的序列化與反序列化

id映射

傳輸協(xié)議

總結(jié)

參考資料

其他資訊

日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

新聞中心

什么是RSC

與SSR、SSG的區(qū)別

RSC的限制

RSC協(xié)議詳解

數(shù)據(jù)的序列化與反序列化

id映射

傳輸協(xié)議

總結(jié)

參考資料

其他資訊

與SSR、SSG的區(qū)別