开源路线图
今年,React Native 团队专注于对 React Native 进行大规模的重新架构。正如 Sophie 在她的React Native 现状文章中提到的,我们已经制定了一个计划,以更好地支持 Facebook 之外蓬勃发展的 React Native 用户和协作者群体。现在是时候分享更多关于我们一直在努力的事情的细节了。在这样做之前,我想阐述一下我们对 React Native 开源的长期愿景。
我们对 React Native 的愿景是…
- 一个健康的 GitHub 仓库。问题和拉取请求在合理的时间内得到处理。
- 提高测试覆盖率。
- 从 Facebook 代码库同步的提交不应破坏开源测试。
- 更大规模的有意义的社区贡献。
- 稳定的 API,使与开源依赖项交互更容易。
- Facebook 使用与开源相同的公共 API
- 遵循语义版本控制的 React Native 版本。
- 一个充满活力的生态系统。由社区维护的高质量 ViewManagers、原生模块和多平台支持。
- 优秀的文档。专注于帮助用户创建高质量的体验,以及最新的 API 参考文档。
我们已经确定了以下重点领域,以帮助我们实现这一愿景。
✂️ 精简核心
我们的目标是减少 React Native 的表面积,方法是删除非核心和未使用的组件。我们将非核心组件转移到社区,使其能够更快地发展。减少的表面积将使管理对 React Native 的贡献变得更容易。
WebView
是我们转移到社区的组件的一个示例。我们正在开发一个工作流程,允许内部团队在我们将这些组件从存储库中删除后继续使用它们。我们已经确定了数十个其他组件,我们将把它们的拥有权交给社区。
🎁 开源内部组件和 🛠更新工具
Facebook 产品团队的 React Native 开发体验可能与开源体验大不相同。开源社区中可能流行的工具在 Facebook 中未使用。可能存在一个内部工具可以实现相同的目的。在某些情况下,Facebook 团队已经习惯了 Facebook 之外不存在的工具。当我们开源我们即将推出的架构工作时,这些差异可能会带来挑战。
我们将努力发布一些这些内部工具。我们还将改进对开源社区中流行的工具的支持。以下列出我们将处理的项目(非详尽列表)
- 开源 JSI 并使社区能够引入自己的 JavaScript VM,替换 RN 初始版本中现有的 JavaScriptCore。我们将在以后的文章中介绍 JSI 是什么,同时您可以从Parashuram 在 React Conf 上的演讲中了解有关 JSI 的更多信息。
- 支持 Android 上的 64 位库。
- 在新架构下启用调试。
- 改进对 CocoaPods、Gradle、Maven 和新的 Xcode 构建系统的支持。
✅ 测试基础设施
当 Facebook 工程师发布代码时,如果它通过了所有测试,则认为它是安全的。这些测试确定更改是否可能破坏我们自己的 React Native 表面。然而,Facebook 使用 React Native 的方式存在差异。这使得我们不知不觉地在开源中破坏了 React Native。
我们将加强我们的内部测试,以确保它们在尽可能接近开源的环境中运行。这将有助于防止破坏这些测试的代码进入开源。我们还将致力于基础设施,以在 GitHub 上更好地测试核心存储库,使未来的拉取请求能够轻松地包含测试。
结合减少的表面积,这将使贡献者能够更快、更有信心地合并拉取请求。
📜 公共 API
Facebook 将通过公共 API 使用 React Native,就像开源一样,以减少意外的破坏性更改。我们已经开始转换内部调用站点以解决此问题。我们的目标是收敛到一个稳定、公开的 API,从而导致在 1.0 版中采用语义版本控制。
📣 沟通
React Native 是 GitHub 上贡献者数量最多的开源项目之一。这让我们非常高兴,我们希望继续保持这种势头。我们将继续开展有助于吸引贡献者的计划,例如提高透明度和公开讨论。文档是 React Native 新手遇到的第一件事之一,但它一直不是优先事项。我们想解决这个问题,首先要恢复自动生成的 API 参考文档,创建更多内容,专注于创建高质量的用户体验,并改进我们的发行说明。
时间线
我们计划在未来一年左右的时间内完成这些项目。其中一些工作已经开始进行,例如JSI 已经进入开源。其他一些工作需要更长的时间才能完成,例如减少表面积。我们将尽最大努力使社区了解我们的进展。请加入我们的讨论和提案存储库,这是 React Native 社区的一项倡议,它导致了本路线图中讨论的若干计划的创建。