緣起

官方介紹影片連結，我也是做這個主題才知道，原來這個概念已經存在那麼久了，那我們快速講解他的成因吧！

影片整理

目的

Dan Abramov 說出了我們前端開發當中需要權衡的三個要點，良好的用戶體驗、不複雜的維護成本及提升效能。

接著他提出了一個例子來闡述開發上的痛點

這是一個很常見的大包小組件組合，問題在於每個組件都需要不同的API回傳資料，但就體驗而言我們更希望這些組件的渲染盡量同時，不同時的話會有要等回傳才能渲染的問題，而且如果關注性能的話，我們也會考慮並行的去 fetch ，所以我們通常會把 fetch 的邏輯放到頂層，然後再透過 Props 或 Context 傳遞下去。

這樣會把可維護性變差，除了看起來噁心，每個元件從邏輯上就不那麼解耦了，我們所以我們會考慮每個元件自己處理 fetch 邏輯。

但是這樣的處理體驗又會變差。

我們會需要從伺服器端 fetch 資料，是因為我們把所有渲染操作放到了用戶端，那如果我們把部分渲染邏輯放伺服器端呢？


這就是 React Server Component 的構想。

那麼現在你可以透過 Next 13 輕鬆體驗到 Server component 的好處。

前後差異點

下面我整理了一些他與 Next 在使用之前與使用之後的一些差異點：

1. 伺服器端渲染的限制：
   • 伺服器端渲染(SSR)的JavaScript組件會在伺服器上轉換為HTML字符串，並傳送到瀏覽器，以實現快速的首次有意義內容繪製。
   • 然而，JavaScript仍然需要在用戶進行互動時進行提取，通常通過hydration步驟實現。
   • SSR通常用於初始頁面載入，因此在hydration完成後，通常不會再次使用。
2. React Server Component：
   • React 的 server component 是對伺服器端渲染的補充，可在不增加 JavaScript 大小的情況下將渲染過程進行到中介抽象格式。
   • server component 與 SSR 並非替代關係，而是一種新的渲染方法，可以快速以中介格式渲染，然後利用 SSR 基礎設施將其轉換為 HTML，從而實現快速的首次繪製(FCP)。
3. 自動代碼拆分(code splitting)：
   • 自動代碼拆分是一種最佳實踐，以根據用戶需要進行動態拆分，減少傳送到客戶端的代碼量。
   • 伺服器元件引入自動代碼拆分，將所有正常引入視為可能的拆分點，並允許開發人員更早地選擇要使用的組件，從而讓客戶端更早地在渲染過程中提取組件。
4. Server component與Next.js SSR的區別：
   • Server component 不會將代碼傳送到客戶端，消除了傳送到客戶端的SSR中的組件代碼，從而減少了客戶端JavaScript捆綁的大小。
   • Server component 允許在 Dom tree 的任何位置訪問後端，而不僅僅是頂層頁面，這擴展了後端訪問的範圍。
   • 可以在保持客戶端 Dom tree 內的狀態的情況下，重新獲取伺服器元件，因為主要傳輸機制比僅限於 HTML 更豐富。

總結

這些重點突顯了伺服器元件作為 SSR 補充的作用，以及它對於解決 SSR 的限制和優化客戶端性能的重要性。
下面我們來總結 server component 和一般 client component 的差異：

這些就是在 Next app router 之下的機制，下一篇我們來理解一下App router的處理機制。

給全新手的大禮包

React基本Hook教學

參考資料

patterns
掘金文章
發布影片
react doc