小編精選 - 技術文章翻譯 · 09月11日

React 伺服器元件：它們並非你所想的那樣（而且它們改變了一切）

您已經聽到了各種討論，也看過了晦澀難懂的 Next.js 文件。也許您甚至嘗試過使用它們，但卻完全搞不懂。 React 伺服器元件 (RSC) 感覺像是自 Hooks 以來 React 最大的思維模式轉變。然而，每個人都誤解了它們。

不要再把它們僅僅視為「在伺服器上執行的元件」。這只是故事的一半。本文將深入探討它們究竟是什麼，為何它們能解決你肯定遇到的問題，以及它們如何從根本上改變 React 架構。

問題：厄運的“瀑布”

想像一下一個典型的 React 應用。你有一個頁面用於獲取部落格文章列表，並且對於每篇文章，它都需要獲取作者的詳細資訊。在一個典型的客戶端 React 應用（即使使用了 SSR）中，這也會形成一個「網路瀑布」。

// Client-side React (e.g., using useEffect)
const BlogPage = () => {
  const [posts, setPosts] = useState(null);

  useEffect(() => {
    fetchPosts().then((data) => setPosts(data)); // 1. Fetch post list
  }, []);

  if (!posts) return <p>Loading posts...</p>;

  return (
    <div>
      {posts.map((post) => (
        <PostCard key={post.id} post={post} /> // 2. Each PostCard fetches its own author
      ))}
    </div>
  );
};

const PostCard = ({ post }) => {
  const [author, setAuthor] = useState(null);

  useEffect(() => {
    fetchAuthor(post.authorId).then((data) => setAuthor(data)); // 3. Fetch author
  }, [post.authorId]);

  return (
    <article>
      <h1>{post.title}</h1>
      {author ? <p>By: {author.name}</p> : <p>Loading author...</p>} {/* 4. Finally render */}
    </article>
  );
};

這個順序安排得讓人很不舒服。作者的取得甚至要等到父元件的文章資料載入完畢才能開始。用戶看到的是一連串令人不快的載入旋轉視窗。

這就是 RSC 旨在解決的問題。

解決方案：單次存取伺服器

React 伺服器元件完全顛覆了這個模型。它們是僅在伺服器上執行的元件。它們不會重新渲染，不使用狀態或效果。它們的工作是獲取資料並描述 UI。

以下是使用 RSC 的相同範例（使用 Next.js App Router）：

// app/blog/page.js
// This is a Server Component by default
async function BlogPage() {
  const posts = await fetchPosts(); // 1. Fetch on the server

  return (
    <div>
      {posts.map((post) => (
        <PostCard key={post.id} post={post} />
      ))}
    </div>
  );
}

// app/components/PostCard.js
async function PostCard({ post }) {
  const author = await fetchAuthor(post.authorId); // 2. Also fetch on the server!

  return (
    <article>
      <h1>{post.title}</h1>
      <p>By: {author.name}</p> {/* 3. No loading state needed! */}
    </article>
  );
}

等等，什麼？就在元件內部 await ？沒錯！這就是魔力所在。兩次資料獲取都發生在伺服器上，在同一個環境中。沒有網路延遲。這就像從本地快取讀取資料，只不過是讀取的是資料庫。

伺服器現在可以一次解析所有資料，並將最終建立的完整 HTML 結構傳送給客戶端。瀑布流消失了。

讓我們直觀地了解差異

這種架構轉變至關重要。下圖展示了兩種模型中資料擷取的關鍵路徑。

圖形模型

交互時間 (TTI) 的差異巨大。客戶端模型受到多個連續網路請求的限制。 RSC 模型則在單一伺服器端執行上下文中完成所有資料處理工作。

為什麼這很重要：大勝利

效能大幅提升：不再出現客戶端資料瀑布流。更快的首次內容繪製 (FCP) 和可互動時間 (TTI)。
更小的客戶端套件：伺服器元件的 JavaScript 程式碼永遠不會傳送到客戶端。這大大減少了包的大小。你用來渲染 Markdown 的繁重函式庫？它仍然保留在伺服器上。
直接後端存取：您可以直接從元件安全地存取資料庫、內部 API 或檔案系統，而無需先建立單獨的 REST/GraphQL API 端點。這極大地提升了開發人員的體驗。
自動快取：伺服器元件的渲染結果可以被框架（如 Next.js）自動緩存，使得後續請求變得非常快。

陷阱（並非全是玫瑰）