跳到主要内容

React Native 开源更新 2019年6月

·8 分钟阅读
Christoph Nakazawa
Christoph Nakazawa
前 Facebook 工程师

代码和社区健康状况

在过去的六个月中,共有 2800 次提交被提交到 React Native,贡献者超过 550 人。来自社区的 400 位贡献者创建了超过 1,150 个拉取请求,其中 820 个拉取请求 已被合并。

尽管我们通过精简核心工作将网站、CLI 和许多模块从 React Native 中分离出来,但在过去的六个月中,平均每天的拉取请求数量已从三个增加到大约六个。现在,未完成的拉取请求的平均数量低于 25 个,我们通常会在数小时或数天内回复建议和评论。

有意义的社区贡献

我们想重点介绍一些我们认为很棒的近期贡献

精简核心

精简核心 的主要动机是将模块从 React Native 中分离出来,放入单独的存储库中,以便它们可以获得更好的维护。在短短六个月内,WebViewNetInfoAsyncStorage网站CLI 等存储库总共收到了超过 800 个拉取请求。除了更好的维护之外,这些项目还可以比 React Native 本身更频繁地独立发布。

我们还借此机会从 React Native 本身中删除过时的 polyfill 和旧版组件。过去,polyfill 是必要的,以支持旧版本 JavaScriptCore (JSC) 中的 MapSet 等语言功能。现在 React Native 附带了一个新版本,这些 polyfill 已被删除。

这项工作仍在进行中,本机和 JavaScript 端还有许多东西需要分离或删除,但早期迹象表明,我们设法扭转了表面积和应用大小增加的趋势:例如,查看 JavaScript 包,大约在一年前的 0.54 版本中,React Native JavaScript 包大小为 530kb,并在短短 6 个月内增长到 0.57 版本的 607kb(+77kb)。现在我们看到主分支上的包大小减少了 28kb,降至 579kb,减少了 100kb 以上!

随着我们完成精简核心工作的第一次迭代,我们将努力更有意地添加新的 API 到 React Native,并将不断评估使 React Native 更小、更快的方法,以及寻找方法来授权社区拥有各种组件的所有权。

用户反馈

六个月前,我们询问社区“您不喜欢 React Native 的什么?”,这很好地概述了人们面临的问题。我们 在几个月前回复了该帖子,现在是总结在首要问题上取得的进展的时候了

  • 升级: React Native 社区团结一致,对升级体验进行了多项改进:自动链接,通过 rn-diff-purge 改进的升级命令,升级帮助网站(即将推出)。我们还将确保通过为每个主要版本发布博客文章来沟通重大更改和令人兴奋的新功能。许多这些改进将使 0.60 版本之后的未来升级变得更加容易。
  • 支持/不确定性: 许多人对拉取请求的缺乏活动以及对 Facebook 在 React Native 上的投资的普遍不确定性感到沮丧。正如我们在上面所展示的,我们可以自信地说,我们已准备好接受更多的拉取请求,并且我们热切期待您的提案和贡献!
  • 性能: React Native 0.59 附带了一个新的、速度快得多的 JavaScriptCore (JSC) 版本。另外,我们一直在努力使默认情况下更容易启用 inline-requires,并且在接下来的几个月里,我们将为您带来更多令人兴奋的更新。
  • 文档: 我们最近开始努力 彻底修改和重写所有 React Native 的文档。如果您正在寻求贡献,我们很乐意得到您的帮助!
  • Xcode 中的警告: 我们 摆脱了所有现有的警告,并正在努力不引入新的警告。
  • 热重载: React 团队正在构建一个 新的热重载系统,该系统将很快集成到 React Native 中。

不幸的是,我们还无法改进所有内容

  • 调试: 我们修复了人们每天都会遇到的许多不方便的错误和问题,但不幸的是,我们在这方面没有取得我们希望的那么大的进展。我们认识到使用 React Native 进行调试并不理想,我们将在未来优先改进这一点。
  • Metro 符号链接: 不幸的是,我们尚未能够为此实施一个简单而直接的解决方案。但是,React Native 用户 分享了各种可能的解决方法,这些方法可能对您有效。

鉴于过去六个月的大量更改,我们想再次问您同样的问题。如果您正在使用最新版本的 React Native,并且您有想要提供反馈的内容,请在我们的新版 “您不喜欢 React Native 的什么?” 上发表评论

持续集成

Facebook 首先将所有拉取请求和内部更改合并到 Facebook 的存储库中,然后将所有提交同步回 GitHub。Facebook 的基础设施与常见的持续集成服务不同,并非所有开源测试都在 Facebook 内部运行。这意味着同步到 GitHub 的提交经常会破坏开源中的测试,这需要花费大量时间来修复。

React Native 团队的 Héctor Ramos 在过去的两个月中花费了大量时间改进 Facebook 和 GitHub 上的 React Native 持续集成系统。现在,大多数开源测试在更改提交到 Facebook 上的 React Native 之前运行,这将使提交同步时 GitHub 上的 CI 保持稳定。

下一步

请务必查看我们关于 React Native 未来的演讲!在接下来的几个月中,Facebook 的 React Native 团队成员将在 Chain ReactReact Native EU 上发表演讲。另外,请留意我们的下一个版本 0.60,它即将到来。这将令人兴奋