關于 React19，你需要了解的前因后果
大家好，我卡頌。
React當前的穩定版本是18.2，發布時間是22年6月，在此之后就沒有新的穩定版本發布。
直到今年2月15日，官方博客[1]才透露下一個穩定版本的計劃。沒錯，他就是React19。
為什么時隔1年多才公布下個穩定版本的計劃？
為什么下個版本直接跳到了19？
18我都還沒升呢，19就來了，是不是要學很多東西？
這篇文章會為你詳細解答這些疑問。
從React16聊起
近年來React最為人津津樂道的版本應該是16.8，這個版本引入了Hooks，為React（乃至整個前端框架領域）注入了新的活力。
再之后的v17沒有新特性引入。既然沒有新特性引入，為什么要發布一個大版本（從16到17）呢？
這是因為從「同步更新」升級到「并發更新」的React，中間存在breaking change。
這么大體量的框架，在升級時需要保證過程盡可能平順。這除了是一種專業、負責的體現，更重要的，版本割裂會造成大量用戶損失（參考當年ng1升級到anuglar2時）。
當升級到18后，React團隊發現 —— 真正升級到18，并大量使用并發特性（比如useTransition）的開發者并不多。
更常見的場景是 —— 知名開源庫集成并發特性，開發者再直接用這些庫。
所以，React團隊轉變策略，將迭代重心從「賦能開發者」轉變為「賦能開源庫」。那么，什么樣的庫受眾最多呢？顯然是框架。
所以，React的重心逐漸變為 —— 賦能上層框架，開發者通過使用上層框架間接使用React。
為什么我說React團隊轉變了策略，而不是React團隊一開始的計劃就是「賦能上層框架」呢？
如果一開始的計劃就是「賦能上層框架」，React團隊就不會花大量精力在「版本的漸進升級上」 —— 反正開發者最終使用的會是上層框架（而不是React），版本割裂上層框架會解決，根本不需要引導開發者升級React。
策略改變造成的影響
策略轉變造成的影響是深遠且廣泛的，這也是為什么18.2后一年多都沒有新的穩定版本出現。
最基本的影響是 —— 特性的迭代流程變了。
React誕生的初衷是為了解決Meta內部復雜的前端應用，所以React之前的特性迭代流程是：
- 新特性開發完成
- 新特性在React內部產品試用，并最終達到穩定狀態
- 開源供廣大開發者使用
但隨著策略轉變為「賦能上層框架」，勢必需要與主流上層框架團隊（主要是Next.js）密切合作。
如果按照原來的迭代流程，上層框架團隊屬于Meta之外的第三方團隊，只能等新特性開源后才能使用，這種合作模式顯然太低效了。
于是，React團隊提出了一個新的特性發布渠道 —— canary，即：新特性開發完成后，可以先打一個canary版本的React供外部試用，等特性穩定后再考慮將其加入穩定版本中。
可能有些存在于canary中的特性永遠不會出現在穩定版本的React中，但不妨礙一些開源庫鎖死canary版本的React，進而使用這些特性。
那么，為什么時隔1年多才公布下個穩定版本的計劃？主要有4個原因。
原因1：新特性主要服務于Next，沒必要出現在穩定版本中
策略改變除了影響「特性的迭代流程」，還讓React團隊成員陷入一個兩難的境地 —— 我該優先服務上層框架還是Meta？
我們可以發現，在之前的迭代流程中，一切都圍繞Meta自身需求展開。React團隊成員作為Meta員工，這個迭代流程再自然不過。
但是，新的迭代流程需要密切與Next團隊合作，那么問題來了 —— 作為Meta員工，新特性應該優先考慮Next的需求還是Meta的需求？
為了完成「賦能上層框架」的任務，顯然應該更多考慮Next的需求。我們能看到一些React團隊成員最終跳槽到Vercel，進入Next團隊。
所以，在此期間產出的特性（比如server action、useFormStatus、useFormState）更多是服務于Next，而不是React。
如果基于這些特性發布新的穩定版本，那不用Next的開發者用不到這些特性，用Next的開發者依賴的是canary React，所以此時升級穩定版本是沒意義的。
原因2：新特性必須滿足各種場景，交付難度大
Next是web框架，圍繞他創造的新React特性只用考慮web這一場景。
但React自身的定位是宿主環境無關的UI庫，還有大量開發者在非web的環境使用React（比如React Native），所以這些特性要出現在穩定版本的React中，必須保證他能適配所有環境。
舉個例子，Server Actions這一特性，用于「簡化客戶端與服務器數據發送的流程」，當前主要應用于Next的App Router模式中。
比如下面代碼中的MyForm組件，當表單提交后，serverAction函數的邏輯會在服務端執行，這樣就能方便的進行IO操作（比如操作數據庫）：
// 服務端代碼
async function serverAction(event) {
'use server'
// 在這里處理服務端邏輯，比如數據庫操作讀寫等
}
function MyForm() {
return (
<form action={serverAction}>
<input name="query" />
<button type="submit">Search</button>
</form>
);
}App Router的場景主要是RSC（React Server Component），除了RSC外，SSR場景下是不是也有表單？不使用服務端相關功能，單純使用React進行客戶端渲染，是不是也有表單的場景？
所以，Server Actions特性后來改名為Actions，因為不止Server場景，其他場景也要支持Actions。
比如下面代碼中，在客戶端渲染的場景使用Actions特性：
// 前端代碼
const search = async (event) => {
event.preventDefault();
const formData = new FormData(event.target);
const query = formData.get('query');
// 使用 fetch 或其他方式發送數據
const response = await fetch('/search', /*省略*/);
// ...處理響應
};
function MyForm() {
return (
<form action={search}>
<input name="query" />
<button type="submit">Search</button>
</form>
);
}你以為這就完了？還早。form組件支持Actions，那開發者自定義的組件能不能支持Actions這種「前、后端交互模式」？
比如下面的Calendar組件，之前通過onSelect事件響應交互：
<Calendar onSelect={eventHandler}>以后能不能用Actions的模式響應交互：
<Calendar selectAction={action}>如何將平平無奇的交互變成Actions交互呢？React團隊給出的答案是 —— 用useTransition包裹。所以，這后面又涉及到useTransition功能的修改。
Actions只是一個例子，可以發現，雖然新特性是以web為始，但為了出現在穩定版本中，需要以「覆蓋全場景」為終，自然提高了交付難度。
原因3：老特性需要兼容的場景越來越多，工作量很大
新特性越來越多，老特性為了兼容這些新特性也必須作出修改，這需要大量的時間開發、測試。
舉兩個例子，Suspense在v16.6就引入了，它「允許組件“等待”某些內容變得可用，并在此期間顯示一個加載指示器（或其他后備內容）」。
Suspense最初只支持懶加載組件（React.lazy）這一場景。隨著React新特性不斷涌現，Suspense又相繼兼容了如下場景：
- Actions提交后的等待場景
- 并發更新的等待場景
- Selective Hydration的加載場景
- RSC流式傳輸的等待場景
- 任何data fetching場景
為了兼容這些場景，Suspense的代碼量已經非?？植懒?，但開發者對此是無感知的。
再舉個和Suspense、useEffect這兩個特性相關的例子。
Suspense為什么能在「中間狀態」與「完成狀態」之間切換？是因為在Suspense的源碼中，他的內部存在一個Offscreen組件，用于完成兩顆子Fiber樹的切換。
React團隊希望將Offscreen組件抽離成一個單獨的新特性（新名字叫Activity組件），起到類似Vue中Keep-Alive組件的作用。
Activity組件既然能讓組件顯/隱，那勢必會影響組件的useEffect的觸發時機。畢竟，如果一個組件隱藏了，但他的useEffect create函數觸發了，會是一件很奇怪的事情。
所以，為了落地Activity組件，useEffect的觸發邏輯又會變得更復雜。
原因4：特性必須形成體系才能交付
雖然這一年React團隊開發了很多特性，但很多特性無法單獨交付，必須構成一個體系后再統一交付。
比如剛才提到的useFormStatus、useFormState是服務于Actions特性的，Actions又是由Server Actions演化而來的，Server Actions又是RSC（React服務端組件）體系下的特性。
單獨將useFormStatus發布在穩定版本中是沒意義的，他屬于RSC體系下的一環。
所以，即使新特性已經準備就緒，他所在的體系還沒準備好的話，那體系下的所有特性都不能在穩定版本中交付。
總結
為什么時隔1年多才公布下個穩定版本的計劃？主要是4個原因：
- 新特性主要服務于Next，沒必要出現在穩定版本中
- 新特性必須滿足各種場景，交付難度大
- 老特性需要兼容的場景越來越多，工作量很大
- 特性必須形成體系才能交付
那為什么下個穩定版本不是v18.x而是v19呢？這是因為部分新特性（主要是Asset Loading、Document Metadata這兩類特性）對于一些應用會產生breaking change，所以需要發一個大版本。
從上述4個原因中的第四點可以知道，既然有v19的消息，勢必是因為「已經有成體系的新特性可以交付」，那是不是意味著要學很多東西呢？
這一點倒不用擔心，如果你不用Next，那你大概率不會接觸到RSC，既然不會接觸RSC，那么RSC體系下的新特性你都不會用到。
v19對你最大的影響可能就是新特性對老API的影響了，比如：
- useContext變為use(promise)
- Activity組件使useEffect的觸發時機更復雜（應該不會在v19的第一個版本中）
這些的學習成本都不大。
關于v19的進一步消息，會在今年5月15～16的React Conf[2]公布。
參考資料
[1]官方博客:https://react.dev/blog/2024/02/15/react-labs-what-we-have-been-working-on-february-2024
[2]React Conf:https://conf.react.dev/
