隨著技術的日新月異，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開發者提供更多選擇和可能性。