簡介

大約十年前，當我開始軟件開發(fā)之路時，我只編寫了 HTML、CSS、JavaScript 和一些 Python 2 腳本；在那段時間，我們僅依賴 PHP 和 SQL 進行服務(wù)器端客戶端-服務(wù)器通信。之后，下一個層次是神奇的詞“反應(yīng)”，就像對狀態(tài)或效果的變化做出反應(yīng)。這是我的理解，沒有深入探討這個問題，有傳言說是 Facebook 工程師制作的；這是我們用來編碼前端部分的方式的重磅炸彈。

隨著軟件開發(fā)的發(fā)展和后端系統(tǒng)變得復雜，React Server Components (RSC) 認為我們的生態(tài)系統(tǒng)迫切需要發(fā)展。這讓我想起了大量 JavaScript 捆綁包和“加載”旋轉(zhuǎn)器無處不在的日子。讓我們探索 RSC 如何改變游戲規(guī)則。

性能革命

RSC 帶來的主要轉(zhuǎn)變不僅是技術(shù)上的，而且是哲學上的。 RSC 不需要將整個組件樹發(fā)送到客戶端，而是讓我們在服務(wù)器上渲染組件，同時保持我們喜歡的 React 交互性。我曾經(jīng)將儀表板應(yīng)用程序遷移到 RSC，這非常簡單，沒有什么特別的，而且儀表板應(yīng)用程序的大小下降了 60%，效果明顯。

這是我最近遇到的一個現(xiàn)實世界的例子：

 // Before: Client Component
 import { ComplexDataGrid } from 'heavy-grid-library';
import { format } from 'date-fns';

export default function Dashboard() {
  const [data, setData] = useState([]);

  useEffect(() => {
    fetchDashboardData().then(setData);
  }, []);

  return <ComplexDataGrid data={data} />;
}

在這種傳統(tǒng)的客戶端方法中，發(fā)生了幾件事：

• 我們正在導入一個與我們的客戶端 JavaScript 捆綁在一起的重型數(shù)據(jù)網(wǎng)格庫。
• 我們使用 useState 在瀏覽器中本地管理我們的數(shù)據(jù)。
• 我們在組件安裝后使用 useEffect 獲取數(shù)據(jù)。
• 在獲取數(shù)據(jù)時用戶會看到加載狀態(tài)。
• 所有數(shù)據(jù)處理都在瀏覽器中進行，可能會降低用戶設(shè)備的速度。

現(xiàn)在，讓我們看看 RSC 版本：

import { sql } from '@vercel/postgres';
import { DataGrid } from './DataGrid';

export default async function Dashboard() {
  const data = await sql`SELECT * FROM dashboard_metrics`;

  return <DataGrid data={data} />;
}

• 該組件默認是異步的 - 不需要 useEffect 或 useState。
• 通過服務(wù)器端查詢直接訪問數(shù)據(jù)庫。
• 無需客戶端數(shù)據(jù)獲取代碼。
• 初始數(shù)據(jù)需要零加載狀態(tài)。
• 數(shù)據(jù)處理發(fā)生在強大的服務(wù)器上，而不是用戶設(shè)備上。
• 導入的DataGrid組件可以更輕量，因為它只需要處理顯示，而不是數(shù)據(jù)獲取。

轉(zhuǎn)變是驚人的。不再有 useEffect，不再有客戶端數(shù)據(jù)獲取，最重要的是，不再有不必??要的 JavaScript 傳送到客戶端。

現(xiàn)實世界的好處

影響不僅僅限于性能指標。在使用 RSC 時，我注意到數(shù)據(jù)庫查詢現(xiàn)在更靠近數(shù)據(jù)源（在上面的示例中不是最佳編碼實踐），組件更簡單、更集中，身份驗證和授權(quán)模式變得更簡單，并且 SEO改進幾乎是免費的，這在 React 世界中是從未發(fā)生過的。

然而，最顯著的優(yōu)勢是開發(fā)者體驗。編寫可以直接訪問數(shù)據(jù)庫的組件（安全！）感覺就像一種超能力。這就像兩全其美：React 基于組件的架構(gòu)，以及 Next.js 最先進的服務(wù)器端渲染的性能優(yōu)勢

權(quán)衡

說實話：RSC 并不完美。心智模型需要時間來掌握，尤其是理解客戶端/服務(wù)器邊界；對我來說，這是一種黑匣子中的復雜操作。我將遵循之前的遷移示例，我們遇到了一些與 RSC 不兼容的第三方庫的障礙。解決方案是什么？混合方法：

 // Before: Client Component
 import { ComplexDataGrid } from 'heavy-grid-library';
import { format } from 'date-fns';

export default function Dashboard() {
  const [data, setData] = useState([]);

  useEffect(() => {
    fetchDashboardData().then(setData);
  }, []);

  return <ComplexDataGrid data={data} />;
}

讓我們來分解一下這種混合方法中發(fā)生的情況：

• use client 指令顯式地將 SearchFilter 標記為客戶端組件。
• SearchFilter 處理只能在客戶端上發(fā)生的用戶交互（onChange 事件）。
• ProductList 仍然是一個服務(wù)器組件，在服務(wù)器端獲取數(shù)據(jù)。
• 組件組合允許我們在適當?shù)那闆r下混合服務(wù)器和客戶端渲染。
• 只有交互部分（SearchFilter）將 JavaScript 傳送到客戶端。
• 數(shù)據(jù)密集的部分（包含產(chǎn)品的 ProductGrid）在服務(wù)器上呈現(xiàn)。

結(jié)論（未來是服務(wù)器優(yōu)先）

RSC 代表的不僅僅是一個新功能 - 它是我們構(gòu)建 React 應(yīng)用程序時所傳達的范例。將昂貴的計算和數(shù)據(jù)獲取轉(zhuǎn)移到服務(wù)器，同時維護 React 的組件模型的能力是革命性的。

對于構(gòu)建數(shù)據(jù)量大的應(yīng)用程序的團隊來說，RSC 提供了一條在不犧牲開發(fā)人員體驗的情況下獲得更好性能的途徑。隨著環(huán)境的成熟和更多庫與 RSC 兼容，我預(yù)計這種模式將成為我們構(gòu)建 React 應(yīng)用程序的默認方式。

分享您的經(jīng)驗

您開始在項目中使用 React Server 組件了嗎？我很樂意在下面的評論中聽到您的意見、挑戰(zhàn)和勝利。
如果本文幫助您更好地了解 RSC，請點贊，并且不要忘記關(guān)注我以更深入地了解現(xiàn)代系統(tǒng)。

關(guān)于作者

Ivan Duarte 是一位擁有自由職業(yè)經(jīng)驗的后端開發(fā)人員。他對網(wǎng)絡(luò)開發(fā)和人工智能充滿熱情，并喜歡通過教程和文章分享他們的知識。在 X、Github 和 LinkedIn 上關(guān)注我，獲取更多見解和更新。

？ 訂閱我們的時事通訊

直接在收件箱中閱讀來自 ByteUp 的文章。

訂閱時事通訊，不要錯過。

？ 立即訂閱 ?

以上是React 服務(wù)器組件：演變的詳細內(nèi)容。更多信息請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！