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 中投入的所有工作都不会白费。