建站
咨詢
售后
建站咨詢
新聞中心
React 團(tuán)隊(duì)希望給 React 社區(qū)提供一個(gè)選項(xiàng)，使其可以在新功能的設(shè)計(jì)接近完成時(shí)就可以選擇使用這些功能，而不必等到它們發(fā)布為穩(wěn)定版本，因此引入了一個(gè)新的官方支持的 Canary 發(fā)布渠道，這個(gè)渠道將使用單獨(dú)的 React 功能與 React 發(fā)布計(jì)劃解耦。
創(chuàng)新互聯(lián)自2013年創(chuàng)立以來(lái)，先為介休等服務(wù)建站，介休等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為介休企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。
概述：
- 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）。
React 功能通常是如何開(kāi)發(fā)的？
通常，每個(gè) React 功能都經(jīng)歷以下階段：
- 首先，開(kāi)發(fā)一個(gè)最初版本，并在 API 名稱前添加 experimental_ 或 unstable_ 前綴。該功能僅在實(shí)驗(yàn)發(fā)布渠道中可用。此外，預(yù)計(jì)該功能將發(fā)生重大變化。
- 在 Meta 找到一個(gè)團(tuán)隊(duì)幫助測(cè)試此功能并提供反饋，隨著功能變得更加穩(wěn)定，與 Meta 的更多團(tuán)隊(duì)合作進(jìn)行試用。
- 從 API 名稱中刪除前綴，并默認(rèn)情況下將該功能置于 main 分支上。此時(shí)，任何 Meta 團(tuán)隊(duì)都可以使用此功能。
- 隨著信心的增加，還會(huì)發(fā)布新功能的 RFC。此時(shí)，該功能適用于廣泛的案例，但可能會(huì)在最后一刻進(jìn)行一些調(diào)整。
- 當(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)定版本。
可以做更多的次要版本嗎？
通常，確實(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ā)布此類更改。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ā)布一樣。
為什么不使用實(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é)奏更新它。這樣做的好處是，它可以讓我們更早地為用戶并按照自己的發(fā)布時(shí)間表發(fā)布單獨(dú)完成的 React 功能和錯(cuò)誤修復(fù)，類似于過(guò)去幾年 React Native 一直在做的事情。缺點(diǎn)是將承擔(dān)額外的責(zé)任來(lái)審查哪些 React 提交被拉入，并與用戶溝通哪些 React 更改包含在發(fā)布中。
提前宣布重大變更和新功能
Canary 版本代表了在任何給定時(shí)間內(nèi)進(jìn)入下一個(gè)穩(wěn)定 React 發(fā)布的最佳猜測(cè)。
以前只在發(fā)布周期結(jié)束時(shí)（進(jìn)行主要發(fā)布時(shí)）宣布重大變更?，F(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ì)其面向用戶的 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 版本，并向其用戶解釋。例如，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)。
參考：https://react.dev/blog/2023/05/03/react-canaries
分享標(biāo)題：React正式推出Canary版本！你了解了嗎？
文章源于：http://m.fisionsoft.com.cn/article/cogpooi.html
