在過去十年中，React 一直是構建網路應用程式的強大工具。
我們都見證了它從笨拙的類元件發展到優雅的鉤子。
但是 React 伺服器元件（RSC）呢？
我們認為沒有人會想到 React 的工作方式會發生如此巨大的轉變。
那麼，React 伺服器元件到底是什麼？它們如何工作？它們有哪些不同於 React 的功能？
為了回答所有這些問題，我們將快速回顧一下基本原理。如果您需要複習，請檢視瞭解 React 學習資源。
在本篇文章中，我們將帶您瞭解為什麼需要 React 伺服器元件、它們是如何工作的，以及 RSC 的一些主要優勢。
什麼是 React 伺服器元件？
React 伺服器元件是構建 React 應用程式的一種新方式。React 伺服器元件不像典型的 React 元件那樣在瀏覽器中執行，而是直接在伺服器上執行。
我認為，RSC 的設計初衷是將後端“元件化”，即相當於 SPA React 在前端所做的後端工作。從理論上講，它們可以在很大程度上消除對 REST 和 GraphQL 等東西的需求，從而使伺服器和客戶端之間的整合更加緊密，因為一個元件可以穿越整個堆疊。– Reddit上的ExternalBison54
由於 RSC 直接在伺服器上執行，它們可以高效地訪問資料庫和API等後端資源，而無需額外的資料獲取層。
但我們為什麼需要 RSC 呢？
要回答這個問題，讓我們倒退一下。
傳統的 React 客戶端渲染（CSR）
React 一直是一個客戶端 UI 庫。
React 背後的核心理念是將整個設計劃分為更小的、獨立的單元，我們稱之為元件。這些元件可以管理自己的私有資料（狀態）並相互傳遞資料（道具）。
將這些元件視為 JavaScript 函式，可以在使用者的瀏覽器中下載和執行。當有人訪問您的應用時，他們的瀏覽器會下載所有元件程式碼，然後 React 會介入並呈現所有內容：
- 瀏覽器下載 HTML、JavaScript、CSS 和其他資產。
- React 會分析 HTML，為使用者互動設定事件監聽器，並檢索任何所需的資料。
- 網站就在你眼前變成了一個功能齊全的 React 應用程式，一切都由瀏覽器和計算機完成。
雖然這個過程很有效，但也有一些缺點：
- 載入時間慢： 載入時間可能會很慢，尤其是對於有大量元件的複雜應用程式，因為現在使用者必須先等待下載所有元件。
- 不利於搜尋引擎優化（SEO）： 最初的 HTML 通常很簡陋，只夠下載 JavaScript，然後再渲染其餘程式碼。這使得搜尋引擎很難理解頁面的內容。
- 應用程式越大，速度越慢： JavaScript 的客戶端處理會造成資源緊張，導致使用者體驗不佳，尤其是在新增更多功能時。
下一個迭代：伺服器端渲染（SSR）
為了解決客戶端渲染帶來的問題，React 社羣採用了伺服器端渲染（SSR）技術。
通過 SSR，伺服器會先將程式碼渲染為 HTML，然後再傳送給客戶端。
然後，完整的渲染 HTML 將被傳輸到瀏覽器/移動裝置上，供使用者隨時檢視，應用程式無需像沒有 SSR 那樣在執行時編譯。
以下是 SSR 的工作原理：
- 伺服器為每個請求渲染初始 HTML。
- 客戶端會收到一個完整的 HTML 結構，從而加快初始頁面的載入速度。
- 然後，客戶端下載 React 和您的應用程式程式碼，這個過程稱為”hydration”，它使頁面具有互動性。
伺服器上呈現的 HTML 結構還沒有任何功能。
React 會新增事件偵聽器、設定內部狀態管理，並在 HTML 下載到裝置後新增其他功能。這種為頁面新增 “生命 ”的過程被稱為 “水合”。
SSR 為何如此有效？
- 更快的初始載入時間：使用者幾乎可以立即看到內容，因為瀏覽器接收到的是完整的 HTML，省去了 JavaScript 載入和執行所需的時間。
- 改進搜尋引擎優化：搜尋引擎可以輕鬆抓取和索引伺服器渲染的 HTML。這種直接訪問可為您的應用程式帶來更好的搜尋引擎優化效果。
- 提高較慢裝置的效能：SSR 減輕了使用者裝置的負擔。伺服器承擔了這些工作，即使在連線速度較慢的情況下，也能使您的應用程式更易於訪問且效能更佳。
不過，SSR 也帶來了一些額外的問題，需要一個更好的解決方案：
- 緩慢的互動時間（TTI）：伺服器端渲染和水合會延遲使用者檢視應用程式並與之互動的時間 ，直到整個過程完成。
- 伺服器負載：伺服器需要做更多的工作，進一步減慢了複雜應用的響應時間，尤其是在有許多使用者同時使用的情況下。
- 設定複雜性：設定和維護可能更加複雜，尤其是大型應用程式。
最後，React 伺服器元件
2020 年 12 月，React 團隊推出了 “Zero-Bundle-Size React Server Components” 或 RSC。
這不僅改變了我們構建 React 應用程式的思路，也改變了 React 應用程式的幕後工作方式。RSC 解決了我們在使用 CSR 和 SSR 時遇到的許多問題。
有了 RSC，React 變成了一個完全的伺服器端框架和一個完全的客戶端框架，這是我們以前從未有過的。這使得伺服器和客戶端程式碼之間的整合比以前更加緊密。-ExternalBison54 在 Reddit 上
現在讓我們來看看 RSC 帶來的好處：
1. 零捆綁大小
RSC 完全在伺服器上呈現，無需向客戶端傳送 JavaScript 程式碼。這將帶來
- 大大縮小了 JavaScript 程式碼包的大小。
- 頁面載入速度更快，尤其是在速度較慢的網路上。
- 在效能較弱的裝置上提高效能。
與 SSR 不同的是，RSC 將整個 React 元件樹傳送到客戶端進行水合，而伺服器只保留伺服器程式碼。這將大大縮小我們談到的客戶端捆綁包，使您的應用程式更輕便、反應更靈敏。
2. 直接後臺訪問
RSC 可以直接與資料庫和檔案系統互動，而無需 API 層。
正如您在下面的程式碼中看到的，courses 變數直接從資料庫中獲取，使用者介面從 courses.map 中列印出 course.id 和 course.name 列表：
async function CourseList() {
const db = await connectToDatabase();
const courses = await db.query('SELECT * FROM courses');
return (
<ul>
{courses.map(course => (
<li key={course.id}>{course.name}</li>
))}
</ul>
);
}
這與傳統的 SSR 相比更為簡單，因為傳統的 SSR 需要設定單獨的 API 路由來獲取單個資料。
3. 自動程式碼分割
有了 RSC，您還可以獲得更細粒度的程式碼拆分和更好的程式碼組織。
React 會將僅用於伺服器的程式碼保留在伺服器上，並確保這些程式碼永遠不會被髮送到客戶端。客戶端元件會被自動識別併傳送到客戶端進行水合。
由於客戶端現在收到的正是一個功能完善的應用程式所需的內容，因此整個捆綁變得非常優化。
另一方面，SSR 需要仔細地手動拆分程式碼，以優化每個附加頁面的效能。
4. 減少瀑布效應和流式渲染
React 伺服器元件結合了流式渲染和並行資料獲取。這種強大的組合大大減少了傳統伺服器端渲染中經常出現的“瀑布效應”。
瀑布效應
瀑布效應 “會降低網路開發速度。從根本上說，它迫使各種操作相互跟進，就像瀑布流過一系列岩石一樣。
每一步都必須等待前一步完成。這種“等待”在資料獲取中尤為明顯。一個應用程式介面呼叫必須在下一個呼叫開始前完成，從而導致頁面載入時間變慢。
流式渲染
流式渲染提供了一種解決方案。伺服器無需等待整個頁面在伺服器上渲染完成，而是可以在使用者介面準備就緒後立即將其傳送到客戶端。
React 伺服器元件能更流暢地呈現和獲取資料。它建立了多個並行工作的伺服器元件，避免了瀑布效應。
一旦使用者介面的任何部分準備就緒，伺服器就會開始向客戶端傳送 HTML。
因此，與伺服器端渲染相比，RSC
- 允許每個元件獨立並行地獲取資料。
- 一旦某個元件的資料準備就緒，伺服器就可以立即對其進行流式處理，而無需等待其他元件跟上。
- 使用者可以看到內容一個接一個地載入，從而增強他們對效能的感知。
5. 與客戶端元件順暢互動
現在，使用 RSC 並不意味著必須跳過客戶端元件。
這兩種元件可以共存，並幫助您建立出色的整體應用程式體驗。
想一想電子商務應用程式。使用 SSR 時，整個應用程式需要在伺服器端呈現。
而在 RSC 中，您可以選擇哪些元件在伺服器端呈現，哪些元件在客戶端呈現。
例如，您可以使用伺服器元件獲取產品資料並呈現初始產品列表頁面。
然後，客戶端元件可以處理使用者互動，如向購物車新增物品或管理產品評論。
您是否應該在路線圖中加入 RSC 實現？
我們的結論？RSC 為 React 開發增添了很多價值。
它們解決了 SSR 和 CSR 方法中一些最緊迫的問題：效能、資料獲取和開發人員體驗。對於剛剛開始編碼的開發人員來說，這讓他們的生活變得更加輕鬆。
現在，您是否應該將 RSC 實現新增到您的路線圖中？我們不得不說–視情況而定。
您的應用程式可能在沒有 RSC 的情況下執行得很好。在這種情況下，新增另一層抽象層可能不會有太大作用。但是，如果您計劃進行擴充套件，並認為 RSC 可以改善應用程式的使用者體驗，那麼可以嘗試進行一些小的改動，然後再進行擴充套件。
評論留言