开源路线图
今年,React Native 团队专注于大规模的 React Native 重新架构。正如 Sophie 在她的 React Native 2018 年状况 文章中提到的那样,我们已经草拟了一个计划,以更好地支持 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 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 社区的一项倡议,促成了本路线图中讨论的几项举措的创建。