隨著技術(shù)的日新月異，React 作為一款領(lǐng)先的前端框架，已經(jīng)在全球范圍內(nèi)贏得了廣泛的認可和應(yīng)用。展望 2024 年，React 的發(fā)展趨勢將如何演變？本文將剖析 React 在未來的技術(shù)動態(tài)、應(yīng)用領(lǐng)域以及社區(qū)生態(tài)等方面的潛在變化，以期提供有價值的參考和啟示。

React 19 要來了

在 React 停更 600 多天之后，React 在博客中透露，將在 2024 年發(fā)布 React 19。文中還提到，React 團隊正在研發(fā)新的編譯器，它將實現(xiàn) React 應(yīng)用中所有緩存的自動化。這意味著過去需要手動進行函數(shù)（useCallback）、值（useMemo）和組件（memo）的緩存的過程，有望在未來被淘汰。React將負責(zé)處理這些緩存，從而避免在每次渲染時都重新計算所有內(nèi)容。

React 19 發(fā)布之后，可能就不需要這些 API 了：

useMemo, useCallback, memo → React Compiler：React 新編譯器將取代這些用于優(yōu)化和緩存的 Hook。

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

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

useContext → use(Context)：（使用Context的方式將變得更加簡潔，可能通過一個新的use函數(shù)來實現(xiàn)。

拋出 promise → use(promise)：對于在Promise中拋出異常的處理將有一個新的use函數(shù)來替代。

<Context.Provider> → <Context>：提供Context的方式將變得更簡潔，可能直接通過Context組件來實現(xiàn)。

Astro + React

去年，Astro 作為 Gatsby 的有力競爭者嶄露頭角，最初主要針對靜態(tài)網(wǎng)站設(shè)計。然而，由于其迅速累積的人氣和不斷增長的功能，Astro 開始積極探索 Web 應(yīng)用和 API 端點的可能性。盡管 Astro 仍然是高性能網(wǎng)站的理想選擇，但 Web 開發(fā)者也開始考慮將其應(yīng)用于更廣泛的用例，超越了其原始的設(shè)想范圍。

圖片

Astro構(gòu)建的網(wǎng)站默認即具備高性能，因其從零開始避免不必要的JavaScript，而將高開銷的渲染工作轉(zhuǎn)至服務(wù)器。盡管靜態(tài)站點生成（SSG）是默認選項，但仍可選擇服務(wù)器端渲染（SSR）。

Astro不局限于React?？稍跓o需UI框架的情況下，直接使用Astro的原生方式在“.astro”文件中構(gòu)建UI組件。同時，Astro也兼容各類組件框架，如React，使你能夠充分利用已有的豐富經(jīng)驗，打造豐富而精致的UI組件。

即便與React等框架結(jié)合使用，Astro 仍不會引入 JavaScript，僅向瀏覽器傳輸HTML和CSS。只有當(dāng)組件需要交互時，服務(wù)器才會按需向客戶端發(fā)送必要的 JavaScript。這一切都與Astro的“默認高性能”理念緊密相連，其背后的驅(qū)動力在于其名為 Island 架構(gòu)的渲染模式。

圖片

借助Astro，已實現(xiàn)的項目不僅展現(xiàn)了卓越的性能和SEO得分，更以美觀的主題和Astro Starlight提供的便捷文檔功能為特色。未來，這種先進的方式將逐漸成為網(wǎng)站建設(shè)的主流標準。期待著 Astro 在未來繼續(xù)為我?guī)砬八从械膭?chuàng)新和無限的可能性。

構(gòu)建工具：Vite vs Turbopack

Turbopack 由 Vercel 與 Webpack 的創(chuàng)始人聯(lián)手打造，旨在成為 Webpack 的繼任者。盡管目前尚未全面投入生產(chǎn)，但它在Next.js的本地開發(fā)環(huán)境中已展現(xiàn)出其潛力。Turbopack 不僅匯集了 Webpack 多年積累的經(jīng)驗，更通過基于Rust的全新架構(gòu)實現(xiàn)了質(zhì)的飛躍。例如，在Webpack中曾被忽視的Tree Shaking和緩存功能，在 Turbopack 中得到了重點支持。

圖片

隨著技術(shù)的發(fā)展，構(gòu)建工具的角色愈發(fā)重要?？蛻舳伺c服務(wù)端組件的交織、應(yīng)用入口點的智能緩存，以及組件級數(shù)據(jù)獲取的需求，都對構(gòu)建工具提出了更高的要求。因此，Vercel 深感需要一種新型的構(gòu)建工具來應(yīng)對這些挑戰(zhàn)。

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

React 狀態(tài)管理

盡管React狀態(tài)管理已經(jīng)是一個老生常談的話題，但隨著新的解決方案（如Signals、Zustand和Recoil）的出現(xiàn)，它們以不同于傳統(tǒng)方法（如Redux和React Hooks）的方式處理狀態(tài)管理，這使得它在React開發(fā)者社區(qū)中仍然是一個熱議的話題。下面來簡要回顧一下兩位主要的競爭者。

• Redux，作為JS應(yīng)用的狀態(tài)容器，通過React-Redux與React緊密結(jié)合。然而，關(guān)于Redux的效用，開發(fā)者們的觀點各異。有的認為它仍是狀態(tài)管理的強大工具，而有的則認為盡管它有效，但并非總是必要，尤其是在中小型應(yīng)用中。隨著React生態(tài)的不斷發(fā)展，似乎有一個共識正在形成：Redux更適用于大型、復(fù)雜的應(yīng)用程序。
• React Hooks（如useState和ReactContext）為跨應(yīng)用共享狀態(tài)提供了簡潔的解決方案。然而，使用Hooks時需要遵循一定的規(guī)則，這可能會讓初學(xué)者感到困惑，甚至對于經(jīng)驗豐富的開發(fā)者來說，也可能難以達到完美的狀態(tài)管理。

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

圖片

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

圖片

Signals，這個狀態(tài)管理模式雖然已有數(shù)年歷史，但仍在React社區(qū)中引發(fā)熱烈討論。通過Preact庫，Signals 現(xiàn)已支持React，旨在解決Hooks和復(fù)雜狀態(tài)管理庫如Redux的痛點。它簡化了跨應(yīng)用存儲和更新值的過程，并僅渲染發(fā)生變化的組件，提高了效率。

2024年React狀態(tài)管理可能會朝著輕量級、集成和兼容性、更好的開發(fā)者體驗、自定義和靈活性以及與其他技術(shù)的結(jié)合等方向發(fā)展。

React Server Components 與 Next.js

React Server Components (RSCs) 是一項由React團隊推出的一種新規(guī)范，包括其底層實現(xiàn)，并在去年通過Next.js的13.4版本得到了社區(qū)的實現(xiàn)和首次采用。不論外界如何議論和挑戰(zhàn)，RSCs 無疑為Web開發(fā)帶來了范式上的巨大轉(zhuǎn)變。

圖片

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

這一新架構(gòu)帶來了眾多優(yōu)勢。雖然難以在此一一列舉，但可以舉一個例子來說明：RSCs允許開發(fā)者在將組件發(fā)送到瀏覽器之前（或通過流式傳輸）在服務(wù)器上執(zhí)行組件級別的數(shù)據(jù)獲取。這意味著曾經(jīng)令人困擾的客戶端到服務(wù)器的網(wǎng)絡(luò)瀑布式請求已成為歷史。如今，這些請求（如果存在的話）在服務(wù)器上更加迅速地完成，從而顯著提升了性能。

強調(diào) RSCs 的這一優(yōu)勢至關(guān)重要，因為它揭示了React生態(tài)系統(tǒng)必須如何與之適應(yīng)。在客戶端-服務(wù)器通信方面，tRPC和react-query等工具扮演著關(guān)鍵角色。然而，在一個無API的世界中，RSCs在服務(wù)器上執(zhí)行大部分數(shù)據(jù)獲取時，這些工具將扮演何種角色成為了一個關(guān)鍵問題。雖然已有一些概念驗證出現(xiàn)，但仍然期待著2024年這一領(lǐng)域?qū)⑷绾卫^續(xù)發(fā)展。

Biome

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

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

圖片

個人對這個項目充滿期待。如果它能夠成功，它或?qū)⒊蔀橥苿蝇F(xiàn)代Web應(yīng)用開發(fā)所有必需功能的高效工具鏈。

TanStack Router 助力構(gòu)建單頁應(yīng)用

盡管 React Server Components 的呼聲越來越高，但 react-query 和r eact-table 等流行React庫的主要推動者Tanner Linsley 認為單頁應(yīng)用（SPA）并未過時。最近，他又發(fā)布了一個新的庫：TanStack Router。

圖片

TanStack Router的發(fā)布時機恰到好處，填補了React生態(tài)系統(tǒng)中一個重要的空白。盡管許多開發(fā)者采用了Next.js和Remix等元框架（這些框架內(nèi)置了路由器，并且也專注于RSCs的實現(xiàn)），但迄今為止，尚未有人為React創(chuàng)建過類型安全的路由。

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

React 身份驗證

隨著多家初創(chuàng)公司和開源項目進軍身份驗證領(lǐng)域，React中的身份驗證功能迎來了新的活力。長期以來，F(xiàn)irebase Authentication、Auth0、Passport.js和NextAuth等方案一直穩(wěn)坐主流地位，但如今，我們迎來了以用戶界面驅(qū)動、成本效益高的新替代方案。

Supabase，作為Google Firebase的開源替代品，不僅提供了全面的身份驗證功能，還整合了PostgreSQL數(shù)據(jù)庫、實時訂閱、存儲以及無服務(wù)器函數(shù)等多樣化工具?？梢赃x擇自我托管或作為付費服務(wù)使用。盡管許多開發(fā)者利用Supabase進行身份驗證，但在其他領(lǐng)域，他們可能會選擇更適合的服務(wù)，如PlanetScale作為 serverless 數(shù)據(jù)庫。

圖片

Clerk 則專注于身份驗證領(lǐng)域，通過為React提供的即插即用組件，使得用戶注冊和登錄過程變得輕松便捷。不僅如此，Clerk還提供了用戶管理和角色分配功能，支持單個或多個組織。對于初創(chuàng)公司來說，Clerk無疑是構(gòu)建最小化可行產(chǎn)品（MVP）時的理想選擇。

最后，不能忽視Lucia的力量。盡管它因與Astro結(jié)合而廣受歡迎，但也可以在其他框架中發(fā)揮作用。Lucia的開源性質(zhì)、社區(qū)支持和清晰的應(yīng)用與數(shù)據(jù)庫之間的抽象層令人印象深刻。特別是其允許在自有數(shù)據(jù)庫中管理用戶的功能，相較于其他身份驗證服務(wù)，這無疑是一個巨大的優(yōu)勢。

React 無頭UI庫

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

shadcn/UI 成為了一個廣受歡迎的UI庫，它創(chuàng)新性地將Tailwind作為核心組件（與CSS變量并駕齊驅(qū)）進行主題定制，以達成高度自定義的設(shè)計目標。與常規(guī)的安裝方式不同，shadcn/UI不是作為Node包來安裝，而是直接復(fù)制粘貼到項目中，使開發(fā)者能夠自由調(diào)整組件以滿足獨特需求。

圖片

這一無頭 UI 庫的趨勢并非始于 shadcn/UI，而是源于開發(fā)者對于獨特設(shè)計和用戶體驗的渴望。在依賴流行的UI庫時，實現(xiàn)獨特設(shè)計往往面臨挑戰(zhàn)。

值得一提的是，為了提高性能和用戶體驗，越來越多的組件開始在服務(wù)器端進行渲染。這一趨勢使得CSS-in-JS解決方案（如Styled Components和Emotion）的使用受到限制，因為這些方案依賴于客戶端/瀏覽器執(zhí)行JavaScript來生成CSS，增加了性能負擔(dān)。相比之下，新興的CSS-in-JS解決方案（如StyleX）通過編譯為實用優(yōu)先的CSS，有效解決了這一問題。

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