2024 年 React 趨勢

隨著技術的日新月異，React 作為一款領先的前端框架，已經在全球範圍內贏得了廣泛的認可和套用。展望 2024 年，React 的發展趨勢將如何演變？本文將剖析 React 在未來的技術動態、套用領域以及社群生態等方面的潛在變化，以期提供有價值的參考和啟示。

React 19 要來了

在 React 停更 600 多天之後，React 在部落格中透露，將在 2024 年釋出 React 19。文中還提到，React 團隊正在研發新的編譯器，它將實作 React 套用中所有緩存的自動化。這意味著過去需要手動進行函式（ useCallback ）、值（ useMemo ）和元件（ memo ）的緩存的過程，有望在未來被淘汰。React將負責處理這些緩存，從而避免在每次渲染時都重新計算所有內容。

React 19 釋出之後，可能就不需要這些 API 了：

useMemo , useCallback , memo → React Compiler：React 新編譯器將取代這些用於最佳化和緩存的 Hook。

forwardRef → ref 作為 prop ： ref 將直接作為內容傳遞，不再需要 forwardRef 。

React.lazy → RSC, promise 作為子元素：Reac t的懶載入功能將被 RSC 或子元素為 Promise 的元件取代。

useContext → use(Context) ：（使用 Context 的方式將變得更加簡潔，可能透過一個新的use函式來實作。

丟擲 promise → use(promise) ：對於在Promise中丟擲異常的處理將有一個新的use函式來替代。

<Context.Provider> → <Context> ：提供 Context 的方式將變得更簡潔，可能直接透過 Context 元件來實作。

Astro + React

去年，Astro 作為 Gatsby 的有力競爭者嶄露頭角，最初主要針對靜態網站設計。然而，由於其迅速累積的人氣和不斷增長的功能，Astro 開始積極探索 Web 套用和 API 端點的可能性。盡管 Astro 仍然是高效能網站的理想選擇，但 Web 開發者也開始考慮將其套用於更廣泛的用例，超越了其原始的設想範圍。

Astro構建的網站預設即具備高效能，因其從零開始避免不必要的JavaScript，而將高開銷的渲染工作轉至伺服器。盡管靜態站點生成（SSG）是預設選項，但仍可選擇伺服器端渲染（SSR）。

Astro不局限於React。可在無需UI框架的情況下，直接使用Astro的原生方式在「.astro」檔中構建UI元件。同時，Astro也相容各類元件框架，如React，使你能夠充分利用已有的豐富經驗，打造豐富而精致的UI元件。

即便與React等框架結合使用，Astro 仍不會引入 JavaScript，僅向瀏覽器傳輸HTML和CSS。只有當元件需要互動時，伺服器才會按需向客戶端發送必要的 JavaScript。這一切都與Astro的「預設高效能」理念緊密相連，其背後的驅動力在於其名為 Island 架構的渲染模式。

借助Astro，已實作的計畫不僅展現了卓越的效能和SEO得分，更以美觀的主題和Astro Starlight提供的便捷文件功能為特色。未來，這種先進的方式將逐漸成為網站建設的主流標準。期待著 Astro 在未來繼續為我帶來前所未有的創新和無限的可能性。

構建工具：Vite vs Turbopack

Turbopack 由 Vercel 與 Webpack 的創始人聯手打造，旨在成為 Webpack 的繼任者。盡管目前尚未全面投入生產，但它在Next.js的本地開發環境中已展現出其潛力。Turbopack 不僅匯集了 Webpack 多年積累的經驗，更透過基於Rust的全新架構實作了質的飛躍。例如，在Webpack中曾被忽視的Tree Shaking和緩存功能，在 Turbopack 中得到了重點支持。

隨著技術的發展，構建工具的角色愈發重要。客戶端與伺服端元件的交織、套用入口點的智慧緩存，以及元件級數據獲取的需求，都對構建工具提出了更高的要求。因此，Vercel 深感需要一種新型的構建工具來應對這些挑戰。

個人而言，曾期待Vite及其強大的伺服端能力能融入Next.js。然而，盡管Vite在過去一年中受到了許多元框架（如Remix）和單頁套用的青睞，Vercel/Next團隊卻選擇了開發Turbopack作為他們的解決方案。這一決策無疑展現了他們對技術革新的追求和對未來打包技術的獨到見解。

React 狀態管理

盡管React狀態管理已經是一個老生常談的話題，但隨著新的解決方案（如Signals、Zustand和Recoil）的出現，它們以不同於傳統方法（如Redux和React Hooks）的方式處理狀態管理，這使得它在React開發者社群中仍然是一個熱議的話題。下面來簡要回顧一下兩位主要的競爭者。

Redux，作為JS套用的狀態容器，透過React-Redux與React緊密結合。然而，關於Redux的效用，開發者們的觀點各異。有的認為它仍是狀態管理的強大工具，而有的則認為盡管它有效，但並非總是必要，尤其是在中小型套用中。隨著React生態的不斷發展，似乎有一個共識正在形成：Redux更適用於大型、復雜的應用程式。

React Hooks（如 useState 和 ReactContext ）為跨套用共享狀態提供了簡潔的解決方案。然而，使用Hooks時需要遵循一定的規則，這可能會讓初學者感到困惑，甚至對於經驗豐富的開發者來說，也可能難以達到完美的狀態管理。

由於這些復雜性和潛在的局限性，越來越多的開發者開始尋找更輕量級、更簡潔的狀態管理解決方案。例如，Zustand就是一個值得關註的庫，它以類似Redux的方式解決問題，但程式碼量更少，更易於理解和使用。事實上，Zustand在今年的JavaScript Rising Stars Report中榮登狀態管理庫榜首，這充分證明了其受歡迎程度和潛力。

除了Zustand之外，還有其他一些備受矚目的狀態管理庫，如Recoil、MobX和Jotai等。這些庫各自具有獨特的特點和優勢，為 React 開發者提供了更多的選擇和可能性。

Signals，這個狀態管理模式雖然已有數年歷史，但仍在React社群中引發熱烈討論。透過Preact庫，Signals 現已支持React，旨在解決Hooks和復雜狀態管理庫如Redux的痛點。它簡化了跨套用儲存和更新值的過程，並僅渲染發生變化的元件，提高了效率。

2024年React狀態管理可能會朝著輕量級、整合和相容性、更好的開發者體驗、自訂和靈活性以及與其他技術的結合等方向發展。

React Server Components 與 Next.js

React Server Components (RSCs) 是一項由React團隊推出的一種新規範，包括其底層實作，並在去年透過Next.js的13.4版本得到了社群的實作和首次采用。不論外界如何議論和挑戰，RSCs 無疑為Web開發帶來了範式上的巨大轉變。

相較於React Hooks，RSCs可能帶來的變革更為深遠，因為它們鼓勵開發者重新思考在大型套用中如何運用React元件。在Next.js及其全新的App Router中，RSCs已成為每位React開發者的新標準。隨著越來越多的框架（甚至超越React的邊界）探索采用（和實作）Server Components，新興的小型框架如 Waku 已率先實作了這一技術。

這一新架構帶來了眾多優勢。雖然難以在此一一列舉，但可以舉一個例子來說明：RSCs允許開發者在將元件發送到瀏覽器之前（或透過流式傳輸）在伺服器上執行元件級別的數據獲取。這意味著曾經令人困擾的客戶端到伺服器的網路瀑布式請求已成為歷史。如今，這些請求（如果存在的話）在伺服器上更加迅速地完成，從而顯著提升了效能。

強調 RSCs 的這一優勢至關重要，因為它揭示了React生態系必須如何與之適應。在客戶端-伺服器通訊方面，tRPC和react-query等工具扮演著關鍵角色。然而，在一個無API的世界中，RSCs在伺服器上執行大部份數據獲取時，這些工具將扮演何種角色成為了一個關鍵問題。雖然已有一些概念驗證出現，但仍然期待著2024年這一領域將如何繼續發展。

Biome

盡管ESLint和Prettier 在 Web 開發中的地位舉足輕重，但它們的設定和協作過程常讓開發者感到棘手。盡管如此，這些工具仍是日常工作的必需品。Biome（原名Rome）正致力於透過提供快速且全面的工具鏈解決方案，來在這一領域開辟新天地。另一個備受矚目的全能工具鏈是 oxc。

Biome憑借其在Rust中建立更高效格式化器的能力，贏得了Prettier 提供的20,000美元獎金。然而，開發者是否會采納這一新工具，仍需時間來驗證。與此同時，關於擺脫對 ESLint 的嚴格依賴、允許使用其他linters的討論正在多個平台熱烈進行，例如在Next.js的GitHub討論區。

個人對這個計畫充滿期待。如果它能夠成功，它或將成為推動現代Web套用開發所有必需功能的高效工具鏈。

TanStack Router 助力構建單頁套用

盡管 React Server Components 的呼聲越來越高，但 react-query 和r eact-table 等流行React庫的主要推動者Tanner Linsley 認為單頁套用（SPA）並未過時。最近，他又釋出了一個新的庫：TanStack Router。

TanStack Router的釋出時機恰到好處，填補了React生態系中一個重要的空白。盡管許多開發者采用了Next.js和Remix等元框架（這些框架內建了路由器，並且也專註於RSCs的實作），但迄今為止，尚未有人為React建立過型別安全的路由。

隨著 TypeScript 在過去幾年中成為行業標準，我對 React 生態系中這個新路由器感到興奮，因為它提供了卓越的TypeScript支持。例如，它將允許開發者以型別安全的方式讀取和寫入URL狀態。也許這個新的路由器還會推動其他成熟的路由器達到這些TypeScript首要標準。

React 身份驗證

隨著多家初創公司和開源計畫進軍身份驗證領域，React中的身份驗證功能迎來了新的活力。長期以來，Firebase Authentication、Auth0、Passport.js和NextAuth等方案一直穩坐主流地位，但如今，我們迎來了以使用者介面驅動、成本效益高的新替代方案。

Supabase，作為Google Firebase的開源替代品，不僅提供了全面的身份驗證功能，還整合了PostgreSQL資料庫、即時訂閱、儲存以及無伺服器函式等多樣化工具。可以選擇自我托管或作為付費服務使用。盡管許多開發者利用Supabase進行身份驗證，但在其他領域，他們可能會選擇更適合的服務，如PlanetScale作為 serverless 資料庫。

Clerk 則專註於身份驗證領域，透過為React提供的隨插即用元件，使得使用者註冊和登入過程變得輕松便捷。不僅如此，Clerk還提供了使用者管理和角色分配功能，支持單個或多個組織。對於初創公司來說，Clerk無疑是構建最小化可行產品（MVP）時的理想選擇。

最後，不能忽視Lucia的力量。盡管它因與Astro結合而廣受歡迎，但也可以在其他框架中發揮作用。Lucia的開源性質、社群支持和清晰的套用與資料庫之間的抽象層令人印象深刻。特別是其允許在自有資料庫中管理使用者的功能，相較於其他身份驗證服務，這無疑是一個巨大的優勢。

React 無頭UI庫

React社群對於UI庫的選擇呈現出逐年變化的態勢。從幾年前的Material UI，到Semantic UI/Ant Design，再到Chakra UI和Mantine UI，最終在去年，焦點集中在了shadcn/UI上。盡管這些選擇都基於設計和可用性的考量，但shadcn/UI卻展現出了獨特之處。

shadcn/UI 成為了一個廣受歡迎的UI庫，它創新性地將Tailwind作為核心元件（與CSS變量並駕齊驅）進行主題客製，以達成高度自訂的設計目標。與常規的安裝方式不同，shadcn/UI不是作為Node包來安裝，而是直接復制貼上到計畫中，使開發者能夠自由調整元件以滿足獨特需求。

這一無頭 UI 庫的趨勢並非始於 shadcn/UI，而是源於開發者對於獨特設計和使用者體驗的渴望。在依賴流行的UI庫時，實作獨特設計往往面臨挑戰。

值得一提的是，為了提高效能和使用者體驗，越來越多的元件開始在伺服器端進行渲染。這一趨勢使得CSS-in-JS解決方案（如 styled Components和Emotion）的使用受到限制，因為這些方案依賴於客戶端/瀏覽器執行JavaScript來生成CSS，增加了效能負擔。相比之下，新興的CSS-in-JS解決方案（如 styleX）透過編譯為實用優先的CSS，有效解決了這一問題。

隨著這一趨勢的發展，期待看到更多創新的UI庫和CSS範式出現。目前，無頭UI庫（如Radix與shadcn/UI）和實用優先的CSS（如Tailwind）已經嶄露頭角，而未來還可能湧現出更多如vanilla-extract、PandaCSS、CVA等替代品，為Web開發者提供更多選擇和可能性。

往期推薦