rfcs下載 - rfcs原始碼下載

rfcs

其他源碼

1.0.0

下載

反應 RFC

許多變更（包括錯誤修復和文件改進）可以透過正常的 GitHub 拉取請求工作流程來實施和審核。

不過，有些更改是“實質性的”，我們要求這些更改經過一些設計過程，並在 React 核心團隊中達成共識。

「RFC」（徵求意見）流程旨在為新功能進入專案提供一致且受控的路徑。

活躍 RFC 列表

貢獻者授權協議 (CLA)

為了接受您的 Pull 請求，我們需要您提交 CLA。您只需執行一次此操作，因此如果您已經為另一個 Facebook 開源專案執行過此操作，那麼您就可以開始了。如果您是第一次提交拉取請求，請告訴我們您已完成 CLA，我們可以與您的 GitHub 使用者名稱進行交叉檢查。

在這裡完成您的 CLA。

何時遵循此流程

如果您打算對 React 或其文件進行「實質」更改，您應該考慮使用此程序。受益於 RFC 的一些例子包括：

建立新 API 表面積的新功能，如果引入，則需要功能標誌。
刪除已作為發布管道一部分提供的功能。
引入新的慣用用法或約定，即使它們不包括對 React 本身的程式碼變更。

有些更改不需要 RFC：

改寫、重組或重構
新增或刪除警告
嚴格改進客觀、數位品質標準的附加內容（加速、更好的瀏覽器支援）
新增的內容只有可能被其他 React 實作者註意到，而對 React 使用者來說是看不見的。

會發生什麼

寫一個能夠被接受的 RFC 是很困難的。儘管如此，這不應該阻止您編寫一個。

React 的 API 表面積非常有限，每個功能都需要與所有其他功能無縫協作。即使在每天全職從事 React 工作的團隊成員中，提高能力並獲得足夠的背景來編寫優秀的 RFC 也需要一年多的時間。

在實務中，React RFC 有兩個目的：

React Team RFC由 React Team 成員經過廣泛（有時是數月或數年）的設計、討論和實驗後提交。實際上，它們構成了迄今為止合併的大多數 RFC。這些 RFC 的目的是為社群預覽設計並提供回饋的機會。我們閱讀對我們發布的 RFC 的每一則評論，回答問題，有時會將回饋納入提案中。由於我們的時間有限，我們不會傾向於為 React 功能編寫 RFC，除非我們非常有信心它符合設計。儘管看起來大多數 React Team RFC 很容易被接受，但實際上這是因為 98% 的想法都被留在了剪輯室地板上。我們非常有信心並達成團隊共識的剩餘 2% 是我們以 RFC 形式公佈以供社群回饋的內容。
任何人都可以提交社區 RFC 。實際上，大多數社區 RFC 不會被合併。我們拒絕 RFC 最常見的原因是它存在重大設計差距或缺陷，不能與所有其他功能協同工作，或不屬於我們對 React 範圍的看法。然而，合併並不是 RFC 成功的唯一標準。即使 API 設計與我們想要的方向不符，我們也發現 RFC 討論對於研究和啟發非常有價值。我們並不總是及時審查社群 RFC，但每當我們開始相關領域的工作時，我們都會檢查該領域的 RFC，並審查社群成員發布的用例和問題。當您發送 RFC 時，您的主要目標不一定是按原樣合併到 React 中，而是與社區成員進行豐富的討論。如果您的建議後來被接受，那就太好了。但即使沒有，也不會白費。由此產生的討論通常會為同一問題空間中的下一個提案提供信息，無論它來自社區還是來自 React 團隊。許多庫作者正在閱讀討論，因此 RFC 通常會導致社區實驗和用戶區解決方案。

我們對 React 團隊 RFC 和社群 RFC 都採用相同程度的嚴格性。它們之間的主要區別在於設計階段：React 團隊 RFC 往往在設計過程結束時提交，而社區 RFC 往往在設計過程開始時提交，作為啟動設計的一種方式。

流程是什麼

簡而言之，要為 React 添加主要功能，通常會先將 RFC 作為 Markdown 檔案合併到 RFC 儲存庫中。此時 RFC 處於「活躍」狀態，並且可以以最終納入 React 的目標來實現。

分叉 RFC 儲存庫 http://github.com/reactjs/rfcs
將0000-template.md複製到text/0000-my-feature.md （其中「my-feature」是描述性的。尚未分配 RFC 編號）。
填入 RFC。注意細節：如果 RFC 沒有提出令人信服的動機，沒有表現出對設計影響的理解，或者對缺點或替代方案不誠實，則往往不會受到歡迎。
提交拉取請求。作為拉取請求，RFC 將收到來自更大社群的設計回饋，作者應該準備好對其進行修改以做出回應。
建立共識並整合回饋。廣泛支持的 RFC 比那些沒有收到任何評論的 RFC 更有可能取得進展。
最終，團隊將決定 RFC 是否為包含在 React 中的候選人。請注意，團隊審核可能需要很長時間，我們建議您先請社群成員審核。
納入 React 的候選 RFC 將進入持續 3 個日曆日的「最終評論期」。此階段的開始將透過 RFC 拉取請求上的評論和標籤來表示。
RFC 可以根據團隊和社群的回饋進行修改。重大修改可能會觸發新的最終評議期。
在公眾討論結束並發表評論總結拒絕理由後，RFC 可能會被團隊拒絕。然後，團隊成員應該關閉與拉取請求相關的 RFC。
RFC 可能會在最終評議期結束時被接受。團隊成員將合併與拉取請求相關的 RFC，此時 RFC 將變為「活動」。

RFC 生命週期

一旦 RFC 變得活躍，作者就可以實現它並將該功能作為拉取請求提交到 React 儲存庫。變得「活躍」並不是橡皮圖章，特別是仍然並不意味著該功能最終會被合併；這確實意味著核心團隊已原則上同意並願意合併。

此外，特定 RFC 已被接受並且處於「活動」狀態這一事實並不意味著為其實現分配了哪些優先級，也不意味著當前是否有人正在處理它。

活動 RFC 的修改可以在後續 PR 中完成。我們努力以反映功能最終設計的方式編寫每個 RFC；但這個過程的本質意味著我們不能期望每個合併的 RFC 都能實際反映下一個主要版本時的最終結果；因此，我們嘗試使每個 RFC 文件與計劃的語言功能保持一定程度的同步，透過對文檔的後續拉取請求來追蹤此類變更。

實作 RFC

RFC 的作者沒有義務實現它。當然，歡迎 RFC 作者（像其他開發人員一樣）在 RFC 被接受後發布實作以供審核。

如果您有興趣緻力於「活躍」RFC 的實現，但無法確定其他人是否已經在從事該工作，請隨時詢問（例如，透過對相關問題發表評論）。

審查 RFC

目前，React 團隊無法承諾及時審核 RFC。當您提交 RFC 時，您的主要目標應該是徵求社群回饋並引發豐富的討論。 React 團隊每隔幾個月重新評估目前的專案和優先順序清單。即使 RFC 設計良好，我們通常也無法承諾立即整合它。然而，我們發現每隔幾個月重新訪問一次開放的 RFC 並看看是否有任何東西引起我們的注意是非常有價值的。每當我們開始研究新的問題空間時，我們也會確保檢查任何相關 RFC 中的先前工作和討論，並與它們互動。

我們會在提交後幾週內閱讀所有 RFC。如果我們認為該設計非常適合 React，並且我們準備好對其進行評估，我們將嘗試盡快對其進行審查。如果我們對設計猶豫不決，或者沒有足夠的資訊來評估它，我們將保持開放，直到收到足夠的社區回饋。我們意識到未能及時收到審核令人沮喪，但您可以確信您在 RFC 中投入的所有工作都不會白費。