跳到主要内容

React Native 开源更新 2019 年 6 月

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

代码和社区健康

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

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

有意义的社区贡献

我们想强调一些我们认为非常棒的近期贡献

精简核心

精简核心(Lean Core)的主要动机是将模块从 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!

随着我们完成精简核心工作的第一个迭代,我们将努力更有意识地对待添加到 React Native 中的新 API,并将不断评估使 React Native 更小、更快的方法,同时寻找赋能社区接管各种组件所有权的方法。

用户反馈

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

  • 升级:React Native 社区共同努力,对升级体验进行了多项改进:自动链接(autolinking)、通过 rn-diff-purge 提供的更好的升级命令、一个升级辅助网站(即将推出)。我们还将确保通过为每个主要版本发布博客文章来传达破坏性变更和激动人心的新功能。这些改进中的许多将使 0.60 版本之后的未来升级显著更容易。
  • 支持 / 不确定性:许多人对拉取请求缺乏活动以及 Facebook 对 React Native 的投资普遍存在不确定性感到沮丧。如我们上面所示,我们可以自信地说,我们已准备好接受更多的拉取请求,并且我们热切期待您的提案和贡献!
  • 性能:React Native 0.59 附带了新版且速度显著更快的 JavaScriptCore (JSC)。另外,我们一直在努力使默认启用内联 require (inline-requires) 变得更容易,并且在接下来的几个月里,我们将为您带来更多激动人心的更新。
  • 文档:我们最近开始了一项工作,以全面修订和重写所有 React Native 的文档。如果您希望做出贡献,我们非常乐意获得您的帮助!
  • Xcode 中的警告:我们已经消除了所有现有警告,并正在努力避免引入新的警告。
  • 热重载:React 团队正在构建一个新的热重载系统,该系统将很快集成到 React Native 中。

不幸的是,我们还未能完全改进所有方面

  • 调试:我们修复了许多日常遇到的不便的 Bug 和问题,但不幸的是,在这方面我们未能取得我们期望的那么多进展。我们认识到使用 React Native 进行调试体验不佳,未来我们将优先改进这一点。
  • Metro 符号链接:不幸的是,我们尚未能为此实现一个简单直接的解决方案。然而,React Native 用户分享了各种可能适合您的变通方法

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

持续集成

Facebook 会先将所有拉取请求和内部更改直接合并到 Facebook 的仓库中,然后再将所有提交同步回 GitHub。Facebook 的基础设施与常见的持续集成服务不同,并非所有开源测试都在 Facebook 内部运行。这意味着同步到 GitHub 的提交经常会在开源中导致测试失败,而修复这些问题需要大量时间。

来自 React Native 团队的 Héctor Ramos 在过去两个月里投入了大量精力,改进了 React Native 在 Facebook 和 GitHub 上的持续集成系统。现在,大部分开源测试在更改提交到 Facebook 的 React Native 之前运行,这将确保在提交同步时 GitHub 上的 CI 保持稳定。

下一步

务必查看我们关于 React Native 未来的演讲!在接下来的几个月里,Facebook React Native 团队的成员将在 Chain ReactReact Native EU 大会上发表演讲。此外,请留意我们的下一个版本 0.60,它即将推出。它会非常令人兴奋 ✨