React 伺服器元件：演進

簡介

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

隨著軟體開發的發展和後端系統變得複雜，React Server Components (RSC) 認為我們的生態系統迫切需要發展。這讓我想起了大量 JavaScript 捆綁包和“加載”旋轉器無處不在的日子。讓我們來探索 RSC 如何改變遊戲規則。

性能革命

RSC 帶來的主要轉變不僅是技術上的，而且是哲學上的。 RSC 不需要將整個元件樹傳送到客戶端，而是讓我們在伺服器上渲染元件，同時保持我們喜歡的 React 互動性。我曾經將儀表板應用程式遷移到 RSC，這非常簡單，沒有什麼特別的，而且儀表板應用程式的大小下降了 60%，效果明顯。

這是我最近遇到的一個現實世界的例子：

 // 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} />;
}

在這種傳統的客戶端方法中，發生了幾件事：

• 我們正在匯入一個與我們的客戶端 JavaScript 捆綁在一起的重型資料網格庫。
• 我們使用 useState 在瀏覽器中本地管理我們的資料。
• 我們在組件安裝後使用 useEffect 取得資料。
• 在取得資料時使用者會看到載入狀態。
• 所有資料處理都在瀏覽器中進行，可能會降低使用者裝置的速度。

現在，讓我們來看看 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。
• 透過伺服器端查詢直接存取資料庫。
• 無需客戶端資料取得代碼。
• 初始資料需要零載入狀態。
• 資料處理發生在強大的伺服器上，而不是使用者設備。
• 匯入的DataGrid元件可以更輕量，因為它只需要處理顯示，而不是資料擷取。

轉變是驚人的。不再有 useEffect，不再有客戶端資料獲取，最重要的是，不再有不必​​要的 JavaScript 傳送到客戶端。

現實世界的好處

影響不僅限於效能指標。在使用RSC 時，我注意到資料庫查詢現在更靠近資料來源（在上面的範例中不是最佳編碼實踐），元件更簡單、更集中，身份驗證和授權模式變得更簡單，並且SEO改進幾乎是免費的，這在React 世界中是從未發生過的。

然而，最顯著的優勢是開發者體驗。編寫可以直接存取資料庫的元件（安全！）感覺就像一種超能力。這就像兩全其美：React 基於元件的架構，以及 Next.js 最先進的伺服器端渲染的效能優勢

權衡

說實話：RSC 並不完美。心智模型需要時間來掌握，尤其是理解客戶端/伺服器邊界；對我來說，這是黑盒子中的複雜操作。我將遵循先前的遷移範例，我們遇到了一些與 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} />;
}

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

• use client 指令明確地將 SearchFilter 標記為客戶端元件。
• SearchFilter 處理只能在客戶端上發生的使用者互動（onChange 事件）。
• ProductList 仍然是伺服器元件，在伺服器端取得資料。
• 元件組合允許我們在適當的情況下混合伺服器和客戶端渲染。
• 只有互動部分（SearchFilter）將 JavaScript 傳送到客戶端。
• 資料密集的部分（包含產品的 ProductGrid）在伺服器上呈現。

結論（未來是伺服器優先）

RSC 代表的不僅僅是一個新功能 - 它是我們建立 React 應用程式時所傳達的範例。將昂貴的運算和資料擷取轉移到伺服器，同時維護 React 的元件模型的能力是革命性的。

對於建立資料量大的應用程式的團隊來說，RSC 提供了一條在不犧牲開發人員體驗的情況下獲得更好效能的途徑。隨著環境的成熟和更多函式庫與 RSC 相容，我預計這種模式將成為我們建立 React 應用程式的預設方式。

分享您的經驗

您開始在專案中使用 React Server 元件了嗎？我很樂意在下面的評論中聽到您的意見、挑戰和勝利。
如果本文幫助您更好地了解 RSC，請點贊，並且不要忘記關注我以更深入地了解現代系統。

關於作者

Ivan Duarte 是一位擁有自由職業經驗的後端開發人員。他對網頁開發和人工智慧充滿熱情，並喜歡透過教學和文章分享他們的知識。在 X、Github 和 LinkedIn 上關注我，以獲取更多見解和更新。

？ 訂閱我們的電子報

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

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

？ 立即訂閱 ?

以上是React 伺服器元件：演進的詳細內容。更多資訊請關注PHP中文網其他相關文章！