大家好，我是Echa。

好消息，最近React 官方 正式 推出了Canary 版本發布渠道。小編把Canary 版本發布渠道定義為“應急綠色通道”。如果React 正式發布Beta 的時候，結果經過開發者社區緊急反饋出現了Bug之類的，那這個時候React 研發團隊會第一時間進行積極處理解決。

React 團隊希望給 React 社區提供一個選項，使其可以在新功能的設計接近完成時就可以選擇使用這些功能，而不必等到它們發布為穩定版本，因此引入了一個新的官方支持的 Canary 發布渠道，這個渠道將使用單獨的 React 功能與 React 發布計劃解耦。

概述：

• React 團隊為 React 引入官方支持的 Canary 發布渠道。由于它得到官方支持，如果出現任何回歸，將像對待穩定版本中的錯誤一樣緊急處理。
• 使用 Canary 可以在它們被發布為穩定的語義化版本之前開始使用單獨的新 React 功能。
• 與實驗功能不同，React Canaries 僅包含有理由相信可以采用的功能，鼓勵框架考慮捆綁固定的 Canary React 版本。
• 將在 React 官方博客上宣布 Canary 版本中的重大更改和新功能。
• React 將在每個穩定版本中繼續遵循語義化版本（Semver）。

全文大綱

1. React 介紹
2. React 功能通常是如何開發的？
3. React 可以做更多的次要版本嗎？
4. React 為什么不使用實驗版本呢？
5. React 提前宣布重大變更和新功能
6. 必須固定 Canaries
7. 示例：React 服務器組件
8. 同時針對穩定版本和 Canary 版本進行測試

React 介紹

官網：https://react.dev/

Github：https://github.com/facebook/react

現在最熱門的前端框架，毫無疑問是 React。

React 起源于 Facebook 的內部項目，因為該公司對市場上所有 JavaScript MVC 框架，都不滿意，就決定自己寫一套，用來架設 Instagram 的網站。做出來以后，發現這套東西很好用，就在2013年5月開源了。

由于 React 的設計思想極其獨特，屬于革命性創新，性能出眾，代碼邏輯卻非常簡單。所以，越來越多的人開始關注和使用，認為它可能是將來 Web 開發的主流工具。

這個項目本身也越滾越大，從最早的UI引擎變成了一整套前后端通吃的 Web App 解決方案。衍生的 React Native 項目，目標更是宏偉，希望用寫 Web App 的方式去寫 Native App。如果能夠實現，整個互聯網行業都會被顛覆，因為同一組人只需要寫一次 UI ，就能同時運行在服務器、瀏覽器和手機。

react特性

1. 專注于視圖層
2. 虛擬dom，最大程度減少直接與dom的交互
3. JSX 是js的擴展
4. 組件化 使得代碼更容易復用
5. 單向響應式的數據流

React的優點

1. React速度很快：它并不直接對DOM進行操作，引入了一個叫做虛擬DOM的概念，安插在javascript邏輯和實際的DOM之間，性能好。最大限度減少DOM交互。
2. 跨瀏覽器兼容：虛擬DOM幫助我們解決了跨瀏覽器問題，它為我們提供了標準化的API，甚至在IE8中都是沒問題的。
3. 一切都是component：代碼更加模塊化，重用代碼更容易，可維護性高。這樣當某個或某些組件出現問題是，可以方便地進行隔離。每個組件都可以進行獨立的開發和測試，并且它們可以引入其它組件。這等同于提高了代碼的可維護性。
4. 單向數據流：Flux是一個用于在JavaScript應用中創建單向數據層的架構，它隨著React視圖庫的開發而被Facebook概念化。減少了重復代碼，這也是它為什么比傳統數據綁定更簡單。
5. 同構、純粹的javascript：因為搜索引擎的爬蟲程序依賴的是服務端響應而不是JavaScript的執行，預渲染你的應用有助于搜索引擎優化。
6. 兼容性好：比如使用RequireJS來加載和打包，而Browserify和Webpack適用于構建大型應用。它們使得那些艱難的任務不再讓人望而生畏。

React 的缺陷

1. React 只是一個視圖庫，而不是一個完整的框架。
2. 對于 Web 開發初學者來說，有一個學習曲線。
3. 將 React 集成到傳統的 MVC 框架中需要一些額外的配置。
4. 代碼復雜性隨著內聯模板和 JSX 的增加而增加。
5. 如果有太多的小組件可能增加項目的龐大和復雜。

React 官網

React 功能通常是如何開發的？

通常，每個 React 功能都經歷以下階段：

1. 首先，開發一個最初版本，并在 API 名稱前添加 experimental_ 或 unstable_ 前綴。該功能僅在實驗發布渠道中可用。此外，預計該功能將發生重大變化。
2. 在 Meta 找到一個團隊幫助測試此功能并提供反饋，隨著功能變得更加穩定，與 Meta 的更多團隊合作進行試用。
3. 從 API 名稱中刪除前綴，并默認情況下將該功能置于 main 分支上。此時，任何 Meta 團隊都可以使用此功能。
4. 隨著信心的增加，還會發布新功能的 RFC。此時，該功能適用于廣泛的案例，但可能會在最后一刻進行一些調整。
5. 當接近發布開源版本時，為該功能編寫文檔，并最終在穩定的 React 發布中發布該功能。

這個流程對迄今發布的大部分功能都很有效。然而，通常存在一個功能一般可用（步驟3）和在開源中發布該功能（步驟5）之間存在顯著差距。React 團隊希望為 React 社區提供一個與 Meta 相同的選項，可以在早期采用單個新功能（在可用時），而無需等待 React 的下一個發布周期。和以前一樣，所有 React 功能最終都會成為穩定版本。

React 可以做更多的次要版本嗎？

通常，確實使用次要版本來引入新功能。然而，這并不總是可行的。有時，新功能與其他尚未完全完成且仍在積極迭代的新功能相互關聯。就無法單獨發布它們，因為它們的實現是相關的。不能單獨對它們進行版本控制，因為它們會影響相同的包（例如，react 和 react-dom）。需要保持對未準備好的部分進行迭代的能力，而不需要進行大量的主要版本發布，這是 semver 所要求的。

在 Meta，通過從 main 分支構建 React，并每周手動更新到特定的固定提交來解決了這個問題。這也是 React Native 在過去幾年中一直遵循的方法。每個穩定版本的 React Native 都固定在 React 存儲庫的 main 分支中的特定提交。這使得 React Native 可以包括重要的 bugfixes，并在框架級別逐步采用新的 React 功能，而不會與全局 React 發布計劃耦合。

React 團隊希望將此工作流程提供給其他框架和策劃設置。例如，一個基于 React 的框架可以在這個框架將此重要變更納入一個穩定的React發布之前，包含與 React 相關的重大變更。這特別有用，因為一些重大變更僅會影響框架集成。這允許框架在不破壞 semver 的情況下在其自己的次要版本中發布此類更改。semver。

通過 Canaries 頻道進行滾動發布將在社區內擁有更緊密的反饋循環，并確保新功能得到全面測試。這個工作流程更接近于 TC39，即 JavaScript 標準委員會，處理編號階段中的變化的方式。新的 React 功能可能在基于 React 構建的框架中可用，然后才進入 React 穩定版本，就像新的 JavaScript 功能在正式批準為規范的一部分之前在瀏覽器中發布一樣。

React 為什么不使用實驗版本呢？

盡管在技術上可以使用實驗版本，但建議不要在生產中使用它們，因為實驗 API 在穩定的過程中可能會經歷重大的破壞性更改（甚至可能完全刪除）。雖然 Canaries 也可能存在錯誤（與任何版本一樣），但 React 團隊計劃今后在博客上宣布 Canaries 中的任何重大突破性更改。Canaries 是最接近 Meta 內部運行代碼的版本，因此通常可以預期它們相對穩定。但是，在更新固定提交之間，需要保持版本固定并手動掃描 GitHub 提交記錄。

預計大多數在策劃設置（如框架）之外使用 React 的人將希望繼續使用穩定版本。但是，如果正在構建一個框架，可能需要考慮將 React 的 Canary 版本捆綁到一個特定的提交，并按照自己的節奏更新它。這樣做的好處是，它可以讓我們更早地為用戶并按照自己的發布時間表發布單獨完成的 React 功能和錯誤修復，類似于過去幾年 React Native 一直在做的事情。缺點是將承擔額外的責任來審查哪些 React 提交被拉入，并與用戶溝通哪些 React 更改包含在發布中。

React 提前宣布重大變更和新功能

Canary 版本代表了在任何給定時間內進入下一個穩定 React 發布的最佳猜測。

以前只在發布周期結束時（進行主要發布時）宣布重大變更。現在，由于 Canaries 是官方支持的一種使用 React 的方法，React 團隊計劃轉向在它們落地時就宣布重大變更和重要的新功能。例如，如果合并了一個將在 Canary 中發布的重大變更，就會在 React 博客上撰寫一篇文章，包括代碼重構和遷移說明（如果有必要）。最后，當穩定的 React 主要版本準備就緒時，將鏈接到已經發布的博客文章。

React 團隊計劃在 API 登陸 Canaries 時記錄它們，即使這些 API 在 Canaries 之外尚不可用。僅在 Canaries 中可用的 API 將在相應頁面上以特殊注釋標記。這將包括像 use 這樣的 API，以及其他一些 API（如 cache 和 createServerContext），將為其發送 RFC。

必須固定 Canaries

如果決定為應用或框架采用 Canary 工作流程，需要確保始終固定正在使用的 Canary 版本。由于 Canary 是預發布版，因此它們可能仍包含重大更改。

示例：React 服務器組件

React 服務器組件約定已經完成，預計不會對其面向用戶的 API 約定進行重大的破壞性更改。然而，現在還不能在 React 的穩定版本中發布對 React 服務器組件的支持，因為仍在研究幾個相互交織的僅限框架的功能（例如資源加載），并且預計還會有更多的重大變更。

這意味著 React 服務器組件已準備好被框架采用。然而，在下一個主要的 React 發布之前，框架采用它們的唯一方法是發布一個固定的 React Canary 版本。（為了避免捆綁兩個 React 版本，希望這樣做的框架需要強制將 react 和 react-dom 解析到他們發布自己的框架所附帶的固定 Canary 版本，并向其用戶解釋。例如，Next.js App Router 就是這樣做的。）

同時針對穩定版本和 Canary 版本進行測試

React 團隊不希望庫作者測試每個 Canary 版本，因為這會非常困難。然而，就像三年前介紹 React 不同預發布渠道時一樣，鼓勵庫針對最新的穩定版本和最新的 Canary 版本運行測試。如果發現未經公布的行為變化，可以在 React 存儲庫中報告錯誤，以便能夠幫助診斷問題。預計隨著這種做法越來越普遍，它將減少將庫升級到 React 新主要版本所需的工作量，因為意外回歸會在它們登陸時被發現。