超越 Next.js：探索替代的 React 伺服器元件框架

React Server Components (RSC) 目前的進展如何？

當 2020 年底 React 團隊引入「零捆綁大小 React 伺服器元件」概念時，許多人一直並且仍然難以理解它。現有框架都不支援新概念，原型也沒有提供建立現實世界應用程式的可用基礎。

現在，四年多過去了，所需的 React 版本仍處於測試階段，尚未發佈到生產環境，並且支援它的唯一大型知名框架由前 React 團隊成員組成。對於少數試圖提供基於 RSC 的替代框架的開發人員來說，這是一個非常悲傷的情況。

為什麼我需要 RSC？

普通的 React 是一個僅專注於提供快速聲明性解決方案來在瀏覽器中建立應用程式的程式庫。瀏覽器中的應用程式始終需要伺服器來取得和儲存其狀態。基於這一事實，大量的解決方案被開發出來並存在於 React 客戶端生態系統中。當越來越多的人開始使用 Typescript 創建後端時，下一個趨勢是具有類型化介面的 RPC 的復興，它在後台創建了 api 端點。

查看 RSC 的這些要求，很快就會發現所有這些都在 RSC 的範圍內，因為它們提供：

• 可以傳回類型化值和承諾的類型化伺服器操作
• 單一伺服器請求更改伺服器上的資料並更新客戶端 UI
• 在伺服器上渲染元件，並且僅將序列化的渲染樹串流傳輸到支援亂序渲染的客戶端

這允許應用程式開發人員使用 React 來定義所有元件，無論它們是在客戶端還是伺服器上渲染。這種整合環境降低了現代應用程式的複雜性，並消除了後端和前端中重複的業務邏輯的冗餘。

哪些框架支援 RSC？

由於 React 函式庫仍是官方測試版，因此它們都不應該被視為生產就緒：

• Next.js v15
• 哇庫
• 反應伺服器
• RedwoodJS v9 - 仍在開發中

目前只有 Next.js 在某種程度上可用於生產。他們的版本 15 是 RSC 的第四次迭代，從 2021 年底開始發布版本 12。

除了列出的框架之外，這裡還有一些存儲庫，其中包含構建 RSC 框架的藍圖 - 如果您想了解更多有關內部結構的信息，請使用它們：

• 文熙
• 雙倍
• 科特坎
• r19

如果您了解更多框架，請在評論中提供它們的連結。

是什麼讓 RSC 難以在框架中實現？

基於 React 用戶端應用程式現有的優秀捆綁器進行轉錄和捆綁非常簡單。有多種選項可以執行此操作，最常用的選項之一是使用 ViteJ 作為開發伺服器和捆綁器。提供 JavaScript 前端和後端堆疊的框架仍然必須提供自己的解決方案來處理開發和生產中的打字稿和捆綁。

使用 RSC，捆綁器需要處理至少三個轉錄和捆綁管道：

1. 瀏覽器客戶端
2. SSR 伺服器
3. RSC 元件渲染器和滅菌 API
4. 可選中間件

在 Vite 版本 6 發布之前，這需要大量特殊程式碼來提供有效的解決方案。 Next.js 只是在版本 15 中切換到 Turbopack 來修復由於 webpack 的複雜性和使用而導致的滯後問題，而 webpack 從來都不是為了處理此類問題而構建的。
Vite 6 的新功能是許多針對框架作者的，並透過他們的新環境 api 提供了一個很好的解決方案。

基於現在元件在完全不同的環境中渲染的事實，需要建立每個React函式庫，透過提供替代內容來處理每個環境的限制。目前，大多數程式庫都可以處理在伺服器上渲染以建立 SSR 內容，但許多瀏覽器特定的 API 缺失。渲染 RSC 元件會為不同的 React 伺服器庫帶來額外的限制，例如，它不支援 React 上下文和狀態以及需要它為所有子元件提供主題的中斷庫。並且庫需要在 packages.json 和 ESM-Modules 中為庫和所有相關子庫提供適當的匯出選項。

RSC 的 React 函式庫沒有提供的第二個部分是路由器。如果沒有處理客戶端和伺服器路由的路由器，React 伺服器元件不知道要在伺服器上呈現哪個狀態。這就是為什麼每個框架都有自己的路由器實現的原因，並且在其 api 標準化之前，為一個框架開發的伺服器和客戶端元件將需要更改以與另一個框架一起使用。

真正的 RSC 框架的所有要求

• React 伺服器元件
  • 沒有伺服器的伺服器元件
  • 帶有伺服器的伺服器元件
  • 非同步組件與伺服器元件
• 伺服器操作
  • 從伺服器元件建立伺服器操作
  • 從客戶端元件匯入伺服器操作
  • 用動作組合伺服器動作
  • 有伺服器操作的表單操作
  • 使用 useActionState 的伺服器操作
  • 使用 useActionState 進行漸進式增強
  • 對伺服器的單一請求，回應中包含 UI 的更新資料
• 指令
  • 「使用客戶端」可讓您標記在客戶端上執行的程式碼。
  • 'use server' 標記可以從客戶端程式碼呼叫的伺服器端函數。
• 捆綁 DEV 和 PROD 中的所有三個目標
• 客戶端路由 API
• 伺服器端路由API

有關 React Server 元件的更多詳細資訊可以在 React 官方文件中找到。

元框架的選用要求：

• 伺服器端渲染（SSR）
• 靜態站點產生 (SSG)
• 巢狀佈局
• 串流媒體
• 檔案系統路由器
• 非 React API 端點
• 中介軟體
• 多重部署目標
• 支援邊緣執行時間（AWS Lambda@Edge、Cloudflare）

Next.js - 為什麼要尋找替代選項？

事實上，Next.js 15 是最主流的 RSC 框架，為什麼我需要考慮替代框架？

這樣做的原因總是基於要達到的目標，但我會嘗試列出一些考慮其他選項有意義的原因：

1. Next.js 是一個複雜的框架，它試圖涵蓋許多可能與給定專案不相關的不同用例
2. 基於所有提供的功能的複雜性和使用情況，除Vercel 之外的其他雲端環境的部署不受官方支持，並且需要付出巨大的努力才能與每個次要版本和主要版本的託管要求發生的變化保持同步。
3. 直到版本 15 將捆綁程式變更為 Turbopack，開發體驗緩慢且遲緩

請記住，本文僅關注提供 RSC 的替代方案，但還有更多框架提供與 RSC 幾乎相似的功能，並且可能是比本文列出的 RSC 框架更好的替代方案。

Waku - 最小的 React 框架

由加藤大師開發：

Waku (wah-ku) 或わく在日文中的意思是「框架」。作為最小的 React 框架，它旨在加速新創公司和機構的開發人員建立中小型 React 專案的工作。其中包括行銷網站、輕型電子商務和網頁應用程式。

我們推薦用於重型電子商務或企業應用程式的其他框架。 Waku 是一種輕量級替代方案，為伺服器元件時代帶來有趣的開發人員體驗。是的，讓 React 開發再次變得有趣！

使用 Waku 啟動新專案非常簡單，您將獲得使用 tailwind 設定的入門範本：
npm create waku@latest

涵蓋了所有基本要求除了在使用變異伺服器操作時在單一請求中傳回客戶端元件的更新之外。目前，任何伺服器突變都需要在客戶端元件中使用 router.reload() 刷新客戶端路由器，這會導致向伺服器發出第二個請求，以將更新後的資料作為 RSC 流載入。

以下可選要求仍在開發中：

• 巢狀檔案系統路由
• 非 React API 端點

支援許多部署目標：Vercel、Netlify、Cloudflare、PartyKit、Deno、AWS Lambda、NodeJS

基於捆綁的複雜性，請準備好在許多第三方庫中出現問題：
https://github.com/dai-shi/waku/issues/423

@lazarv/react-server - 使用伺服器端渲染建立 React 應用程式最簡單的方法

由 Viktor Lázár 開發：

我創建了 @lazarv/react-server 因為我想透過 Vite ❤️ 使用 React 伺服器元件和伺服器操作。對於大多數小型應用程式來說，Next.js 太多、太重、太慢。我希望獲得與使用 Node.js 運行簡單 JavaScript 檔案相同的體驗。這個框架試圖盡可能地不發表意見。你可能可以實現你想要的任何事情。唯一的限制是它將使用自己的 React 版本。您甚至不需要在專案中安裝 React。這一切都包含在框架中。我希望您會喜歡使用這個框架，就像我喜歡創建它並使用它來創建本文檔一樣。 - 拉札爾夫

使用這個框架學習 React 伺服器元件是一件輕而易舉的事！您只需要一個包含有效反應伺服器元件並執行命令的檔案：

./App.jsx

export default function App() {
  return <h1 id="Hello-World">Hello, World!</h1>
}

npx @lazarv/react-server ./App.jsx

教學部分有一個關於如何入門的很好的文件和幾個範例專案。

涵蓋所有基本要求除了在使用變異伺服器操作時在單一請求中傳回客戶端元件的更新。

由於執行時間依賴 NodeJS API，因此其他執行時間例如目前不支援（AWS Lambda@Edge、Cloudflare）。

此外還存在以下功能：

• 存取伺服器元件和操作中的 HTTP 上下文
• 快取任何伺服器資料和伺服器回應，並根據關鍵訂單標籤重新驗證
• 錯誤處理
• 部分預先渲染 - 將 JSX 頁面的一部分定義為靜態 shell
• NodeJS 叢集模式
• 微前端 - 將您的應用程式分成更小、更易於管理的部分。使用 RemoteComponent 元件從遠端 URL 載入微前端，並使用伺服器端渲染在您的應用程式中渲染它

部署目標：NodeJS、Vercel - 開發中的適配器：Netlify、Cloudflare、sst

支援開箱即用的 Tailwind CSS、TanStack 查詢、Mantine UI、Material UI。

RedwoodJS - 有效的單一開發框架

湯姆·普雷斯頓-沃納提供：

Redwood 是全端 JavaScript 應用程式框架。
包括電池、後端、React、約定和意見。

仍在開發中並且僅適用於 Node v20 和 Yarn 4：

export default function App() {
  return <h1 id="Hello-World">Hello, World!</h1>
}

然後您需要啟用一些實驗性功能：

npx @lazarv/react-server ./App.jsx

最後，建造並服務：

npx -y create-redwood-app@canary -y ~/rsc_app
cd ~/rsc_app

作為 setup-rsc 命令的一部分，為您創建了一個準系統 RSC 應用程序，演示了伺服器組件內部渲染的客戶端組件

部署目標：Vercel、Netlify、Render、GCP 或 AWS（透過 Coherence）、AWS（透過 Flightcontrol）、NodeJS

比較：Next.js 與替代方案

	Next.js	WAKU	React-server	RedwoodJS
DEV-Environment / Bundling	Turbopack	Vite 5	Vite 6	Vite
Rendering	SSR, ISR, SSG, CSR	SSR, SSG, CSR	SSR, SSG, CSR, Micro-Frontends	SSR, SSG, CSR
Caching Layers	Yes	No	Yes	??
Deployment Target	Vercel, NodeJS	Vercel, Netlify, Cloudflare, Deno, AWS Lambda, PartyKit, NodeJS	Vercel, NodeJS, sst (AWS Lambda)	Vercel, Netlify, AWS, NodeJS
Community	Very Big	Tiny	Just Starting	Small
Open Source Financing	Vercel	Donations	Donations	Privately Funded by a Rich Guy

結論

重點回顧：

• RSC 為現代 Web 開發提供了強大的範例。
• Next.js 很優秀，但不是唯一的選擇。
• 替代方案提供了滿足不同需求的多種功能，但錯過了單一請求突變 UI 更新。
• React 生態系統中的圖書館尚未準備好擁抱 RSC

嘗試框架以找到最適合您的專案的框架。

以上是超越 Next.js：探索替代的 React 伺服器元件框架的詳細內容。更多資訊請關注PHP中文網其他相關文章！