大家好，我卡頌。

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/