开源路线图
今年,React Native 团队专注于React Native 的大规模重构。正如 Sophie 在她的React Native 现状博文中提到的,我们已经制定了一个计划,以更好地支持 Facebook 之外蓬勃发展的 React Native 用户和贡献者。现在是时候分享我们一直在努力的更多细节了。在此之前,我想阐述一下我们对开源 React Native 的长期愿景。
我们对 React Native 的愿景是……
- 一个健康的 GitHub 仓库。 问题和拉取请求在合理的时间内得到处理。
- 增加测试覆盖率。
- 从 Facebook 代码仓库同步出来的提交不应破坏开源测试。
- 更高水平的有意义的社区贡献。
- 稳定的 API,使其更容易与开源依赖项进行交互。
- Facebook 使用与开源相同的公共 API
- 遵循语义化版本控制的 React Native 版本。
- 一个充满活力的生态系统。 社区维护的高质量 ViewManager、原生模块和多平台支持。
- 出色的文档。 专注于帮助用户创建高质量体验,以及最新的 API 参考文档。
我们已确定以下重点领域,以帮助我们实现这一愿景。
✂️ 精益核心
我们的目标是通过移除非核心和未使用的组件来减少 React Native 的表面积。我们将把非核心组件转移给社区,使其能够更快地发展。减少的表面积将使管理对 React Native 的贡献变得更容易。
WebView
是我们转移给社区的一个组件示例。我们正在研究一种工作流程,该工作流程将允许内部团队在我们从仓库中移除这些组件后继续使用它们。我们已经确定了数十个组件,我们将把它们的所有权转交给社区。
🎁 开源内部组件和 🛠更新的工具
Facebook 产品团队的 React Native 开发体验可能与开源社区大相径庭。开源社区中流行的工具在 Facebook 不会被使用。可能有一个内部工具实现相同的目的。在某些情况下,Facebook 团队已经习惯了 Facebook 之外不存在的工具。当我们开源即将到来的架构工作时,这些差异可能会带来挑战。
我们将努力发布一些内部工具。我们还将改进对开源社区流行工具的支持。以下是我们将要解决的项目的不完全列表
- 开源 JSI 并使社区能够引入他们自己的 JavaScript 虚拟机,取代 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 社区的一项倡议,它促成了本路线图中讨论的几项倡议的创建。