大家好，我是Echa。

好消息，最近React 官方 正式 推出了Canary 版本發(fā)布渠道。小編把Canary 版本發(fā)布渠道定義為“應(yīng)急綠色通道”。如果React 正式發(fā)布Beta 的時(shí)候，結(jié)果經(jīng)過(guò)開(kāi)發(fā)者社區(qū)緊急反饋出現(xiàn)了Bug之類(lèi)的，那這個(gè)時(shí)候React 研發(fā)團(tuán)隊(duì)會(huì)第一時(shí)間進(jìn)行積極處理解決。

React 團(tuán)隊(duì)希望給 React 社區(qū)提供一個(gè)選項(xiàng)，使其可以在新功能的設(shè)計(jì)接近完成時(shí)就可以選擇使用這些功能，而不必等到它們發(fā)布為穩(wěn)定版本，因此引入了一個(gè)新的官方支持的 Canary 發(fā)布渠道，這個(gè)渠道將使用單獨(dú)的 React 功能與 React 發(fā)布計(jì)劃解耦。

概述：

• React 團(tuán)隊(duì)為 React 引入官方支持的 Canary 發(fā)布渠道。由于它得到官方支持，如果出現(xiàn)任何回歸，將像對(duì)待穩(wěn)定版本中的錯(cuò)誤一樣緊急處理。
• 使用 Canary 可以在它們被發(fā)布為穩(wěn)定的語(yǔ)義化版本之前開(kāi)始使用單獨(dú)的新 React 功能。
• 與實(shí)驗(yàn)功能不同，React Canaries 僅包含有理由相信可以采用的功能，鼓勵(lì)框架考慮捆綁固定的 Canary React 版本。
• 將在 React 官方博客上宣布 Canary 版本中的重大更改和新功能。
• React 將在每個(gè)穩(wěn)定版本中繼續(xù)遵循語(yǔ)義化版本（Semver）。

全文大綱

1. React 介紹
2. React 功能通常是如何開(kāi)發(fā)的？
3. React 可以做更多的次要版本嗎？
4. React 為什么不使用實(shí)驗(yàn)版本呢？
5. React 提前宣布重大變更和新功能
6. 必須固定 Canaries
7. 示例：React 服務(wù)器組件
8. 同時(shí)針對(duì)穩(wěn)定版本和 Canary 版本進(jìn)行測(cè)試

React 介紹

官網(wǎng)：https://react.dev/

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

現(xiàn)在最熱門(mén)的前端框架，毫無(wú)疑問(wèn)是 React。

React 起源于 Facebook 的內(nèi)部項(xiàng)目，因?yàn)樵摴緦?duì)市場(chǎng)上所有 JavaScript MVC 框架，都不滿意，就決定自己寫(xiě)一套，用來(lái)架設(shè) Instagram 的網(wǎng)站。做出來(lái)以后，發(fā)現(xiàn)這套東西很好用，就在2013年5月開(kāi)源了。

由于 React 的設(shè)計(jì)思想極其獨(dú)特，屬于革命性創(chuàng)新，性能出眾，代碼邏輯卻非常簡(jiǎn)單。所以，越來(lái)越多的人開(kāi)始關(guān)注和使用，認(rèn)為它可能是將來(lái) Web 開(kāi)發(fā)的主流工具。

這個(gè)項(xiàng)目本身也越滾越大，從最早的UI引擎變成了一整套前后端通吃的 Web App 解決方案。衍生的 React Native 項(xiàng)目，目標(biāo)更是宏偉，希望用寫(xiě) Web App 的方式去寫(xiě) Native App。如果能夠?qū)崿F(xiàn)，整個(gè)互聯(lián)網(wǎng)行業(yè)都會(huì)被顛覆，因?yàn)橥唤M人只需要寫(xiě)一次 UI ，就能同時(shí)運(yùn)行在服務(wù)器、瀏覽器和手機(jī)。

react特性

1. 專(zhuān)注于視圖層
2. 虛擬dom，最大程度減少直接與dom的交互
3. JSX 是js的擴(kuò)展
4. 組件化 使得代碼更容易復(fù)用
5. 單向響應(yīng)式的數(shù)據(jù)流

React的優(yōu)點(diǎn)

1. React速度很快：它并不直接對(duì)DOM進(jìn)行操作，引入了一個(gè)叫做虛擬DOM的概念，安插在javascript邏輯和實(shí)際的DOM之間，性能好。最大限度減少DOM交互。
2. 跨瀏覽器兼容：虛擬DOM幫助我們解決了跨瀏覽器問(wèn)題，它為我們提供了標(biāo)準(zhǔn)化的API，甚至在IE8中都是沒(méi)問(wèn)題的。
3. 一切都是component：代碼更加模塊化，重用代碼更容易，可維護(hù)性高。這樣當(dāng)某個(gè)或某些組件出現(xiàn)問(wèn)題是，可以方便地進(jìn)行隔離。每個(gè)組件都可以進(jìn)行獨(dú)立的開(kāi)發(fā)和測(cè)試，并且它們可以引入其它組件。這等同于提高了代碼的可維護(hù)性。
4. 單向數(shù)據(jù)流：Flux是一個(gè)用于在JavaScript應(yīng)用中創(chuàng)建單向數(shù)據(jù)層的架構(gòu)，它隨著React視圖庫(kù)的開(kāi)發(fā)而被Facebook概念化。減少了重復(fù)代碼，這也是它為什么比傳統(tǒng)數(shù)據(jù)綁定更簡(jiǎn)單。
5. 同構(gòu)、純粹的javascript：因?yàn)樗阉饕娴呐老x(chóng)程序依賴(lài)的是服務(wù)端響應(yīng)而不是JavaScript的執(zhí)行，預(yù)渲染你的應(yīng)用有助于搜索引擎優(yōu)化。
6. 兼容性好：比如使用RequireJS來(lái)加載和打包，而B(niǎo)rowserify和Webpack適用于構(gòu)建大型應(yīng)用。它們使得那些艱難的任務(wù)不再讓人望而生畏。

React 的缺陷

1. React 只是一個(gè)視圖庫(kù)，而不是一個(gè)完整的框架。
2. 對(duì)于 Web 開(kāi)發(fā)初學(xué)者來(lái)說(shuō)，有一個(gè)學(xué)習(xí)曲線。
3. 將 React 集成到傳統(tǒng)的 MVC 框架中需要一些額外的配置。
4. 代碼復(fù)雜性隨著內(nèi)聯(lián)模板和 JSX 的增加而增加。
5. 如果有太多的小組件可能增加項(xiàng)目的龐大和復(fù)雜。

React 官網(wǎng)

React 功能通常是如何開(kāi)發(fā)的？

通常，每個(gè) React 功能都經(jīng)歷以下階段：

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

這個(gè)流程對(duì)迄今發(fā)布的大部分功能都很有效。然而，通常存在一個(gè)功能一般可用（步驟3）和在開(kāi)源中發(fā)布該功能（步驟5）之間存在顯著差距。React 團(tuán)隊(duì)希望為 React 社區(qū)提供一個(gè)與 Meta 相同的選項(xiàng)，可以在早期采用單個(gè)新功能（在可用時(shí)），而無(wú)需等待 React 的下一個(gè)發(fā)布周期。和以前一樣，所有 React 功能最終都會(huì)成為穩(wěn)定版本。

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

通常，確實(shí)使用次要版本來(lái)引入新功能。然而，這并不總是可行的。有時(shí)，新功能與其他尚未完全完成且仍在積極迭代的新功能相互關(guān)聯(lián)。就無(wú)法單獨(dú)發(fā)布它們，因?yàn)樗鼈兊膶?shí)現(xiàn)是相關(guān)的。不能單獨(dú)對(duì)它們進(jìn)行版本控制，因?yàn)樗鼈儠?huì)影響相同的包（例如，react 和 react-dom）。需要保持對(duì)未準(zhǔn)備好的部分進(jìn)行迭代的能力，而不需要進(jìn)行大量的主要版本發(fā)布，這是 semver 所要求的。

在 Meta，通過(guò)從 main 分支構(gòu)建 React，并每周手動(dòng)更新到特定的固定提交來(lái)解決了這個(gè)問(wèn)題。這也是 React Native 在過(guò)去幾年中一直遵循的方法。每個(gè)穩(wěn)定版本的 React Native 都固定在 React 存儲(chǔ)庫(kù)的 main 分支中的特定提交。這使得 React Native 可以包括重要的 bugfixes，并在框架級(jí)別逐步采用新的 React 功能，而不會(huì)與全局 React 發(fā)布計(jì)劃耦合。

React 團(tuán)隊(duì)希望將此工作流程提供給其他框架和策劃設(shè)置。例如，一個(gè)基于 React 的框架可以在這個(gè)框架將此重要變更納入一個(gè)穩(wěn)定的React發(fā)布之前，包含與 React 相關(guān)的重大變更。這特別有用，因?yàn)橐恍┲卮笞兏鼉H會(huì)影響框架集成。這允許框架在不破壞 semver 的情況下在其自己的次要版本中發(fā)布此類(lèi)更改。semver。

通過(guò) Canaries 頻道進(jìn)行滾動(dòng)發(fā)布將在社區(qū)內(nèi)擁有更緊密的反饋循環(huán)，并確保新功能得到全面測(cè)試。這個(gè)工作流程更接近于 TC39，即 JavaScript 標(biāo)準(zhǔn)委員會(huì)，處理編號(hào)階段中的變化的方式。新的 React 功能可能在基于 React 構(gòu)建的框架中可用，然后才進(jìn)入 React 穩(wěn)定版本，就像新的 JavaScript 功能在正式批準(zhǔn)為規(guī)范的一部分之前在瀏覽器中發(fā)布一樣。

React 為什么不使用實(shí)驗(yàn)版本呢？

盡管在技術(shù)上可以使用實(shí)驗(yàn)版本，但建議不要在生產(chǎn)中使用它們，因?yàn)閷?shí)驗(yàn) API 在穩(wěn)定的過(guò)程中可能會(huì)經(jīng)歷重大的破壞性更改（甚至可能完全刪除）。雖然 Canaries 也可能存在錯(cuò)誤（與任何版本一樣），但 React 團(tuán)隊(duì)計(jì)劃今后在博客上宣布 Canaries 中的任何重大突破性更改。Canaries 是最接近 Meta 內(nèi)部運(yùn)行代碼的版本，因此通?？梢灶A(yù)期它們相對(duì)穩(wěn)定。但是，在更新固定提交之間，需要保持版本固定并手動(dòng)掃描 GitHub 提交記錄。

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

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

Canary 版本代表了在任何給定時(shí)間內(nèi)進(jìn)入下一個(gè)穩(wěn)定 React 發(fā)布的最佳猜測(cè)。

以前只在發(fā)布周期結(jié)束時(shí)（進(jìn)行主要發(fā)布時(shí)）宣布重大變更。現(xiàn)在，由于 Canaries 是官方支持的一種使用 React 的方法，React 團(tuán)隊(duì)計(jì)劃轉(zhuǎn)向在它們落地時(shí)就宣布重大變更和重要的新功能。例如，如果合并了一個(gè)將在 Canary 中發(fā)布的重大變更，就會(huì)在 React 博客上撰寫(xiě)一篇文章，包括代碼重構(gòu)和遷移說(shuō)明（如果有必要）。最后，當(dāng)穩(wěn)定的 React 主要版本準(zhǔn)備就緒時(shí)，將鏈接到已經(jīng)發(fā)布的博客文章。

React 團(tuán)隊(duì)計(jì)劃在 API 登陸 Canaries 時(shí)記錄它們，即使這些 API 在 Canaries 之外尚不可用。僅在 Canaries 中可用的 API 將在相應(yīng)頁(yè)面上以特殊注釋標(biāo)記。這將包括像 use 這樣的 API，以及其他一些 API（如 cache 和 createServerContext），將為其發(fā)送 RFC。

必須固定 Canaries

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

示例：React 服務(wù)器組件

React 服務(wù)器組件約定已經(jīng)完成，預(yù)計(jì)不會(huì)對(duì)其面向用戶(hù)的 API 約定進(jìn)行重大的破壞性更改。然而，現(xiàn)在還不能在 React 的穩(wěn)定版本中發(fā)布對(duì) React 服務(wù)器組件的支持，因?yàn)槿栽谘芯繋讉€(gè)相互交織的僅限框架的功能（例如資源加載），并且預(yù)計(jì)還會(huì)有更多的重大變更。

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

同時(shí)針對(duì)穩(wěn)定版本和 Canary 版本進(jìn)行測(cè)試

React 團(tuán)隊(duì)不希望庫(kù)作者測(cè)試每個(gè) Canary 版本，因?yàn)檫@會(huì)非常困難。然而，就像三年前介紹 React 不同預(yù)發(fā)布渠道時(shí)一樣，鼓勵(lì)庫(kù)針對(duì)最新的穩(wěn)定版本和最新的 Canary 版本運(yùn)行測(cè)試。如果發(fā)現(xiàn)未經(jīng)公布的行為變化，可以在 React 存儲(chǔ)庫(kù)中報(bào)告錯(cuò)誤，以便能夠幫助診斷問(wèn)題。預(yù)計(jì)隨著這種做法越來(lái)越普遍，它將減少將庫(kù)升級(jí)到 React 新主要版本所需的工作量，因?yàn)橐馔饣貧w會(huì)在它們登陸時(shí)被發(fā)現(xiàn)。