经过 React Native 社区中 6 位贡献者的 20 多个 pull request，我们激动地推出 react-native doctor，一个新命令，可帮助你入门、排除故障并自动修复开发环境中的错误。doctor 命令深受 Expo 和 Homebrew 自身的 doctor 命令的启发，并借鉴了 Jest 的 UI 灵感。

我们激动地宣布 React Native 0.61 发布，其中包含我们称之为快速刷新的全新重载体验。

快速刷新​

当我们向 React Native 社区询问 常见的痛点 时，最常见的答案之一是“热重载”功能已损坏。它对于函数组件无法可靠地工作，经常无法更新屏幕，并且对错别字和错误不具有弹性。我们听说大多数人将其关闭，因为它太不可靠了。

在 React Native 0.61 中，我们将现有的“实时重载”（保存时重载）和“热重载”功能统一到一个名为“快速刷新”的新功能中。快速刷新是从头开始实现的，遵循以下原则

• 快速刷新完全支持现代 React，包括函数组件和 Hooks。
• 快速刷新在错别字和其他错误后优雅地恢复，并在需要时回退到完全重载。
• 快速刷新不执行侵入式代码转换，因此它足够可靠，可以默认启用。

要观看快速刷新的实际效果，请查看此视频

试用一下，让我们知道你的想法！如果你愿意，可以在开发菜单（iOS 上为 Cmd+D，Android 上为 Cmd+M 或 Ctrl+M）中将其关闭。打开和关闭是即时的，因此你可以随时执行此操作。

以下是一些快速刷新技巧

• 默认情况下，快速刷新会保留函数组件（和 Hooks！）中的 React 本地状态。
• 如果你需要在每次编辑时重置 React 状态，你可以向包含该组件的文件添加特殊的 // @refresh reset 注释。
• 快速刷新始终重新挂载类组件，而不保留状态。这确保了它的可靠性。
• 我们都会在代码中犯错！快速刷新会在你保存文件后自动重试渲染。修复语法或运行时错误后，你无需手动重载应用。
• 在编辑过程中添加 console.log 或 debugger 语句是一种简洁的调试技术。

请在 GitHub 上报告有关快速刷新的任何问题，我们将进行调查。

其他改进​

• 修复了 use_frameworks! CocoaPods 支持。 在 0.60 中，我们进行了一些更新以默认集成 CocoaPods。不幸的是，这破坏了使用 use_frameworks! 的构建。这个问题已在 0.61 中修复，使其更容易将 React Native 集成到需要使用动态框架构建的 iOS 项目中。
• 添加 useWindowDimensions Hook。 这个新的 Hook 自动提供并订阅尺寸更新，并且在大多数情况下可以代替 Dimensions API 使用。
• React 已升级到 16.9。 此版本弃用了 UNSAFE_ 生命周期方法的旧名称，包含对 act 的改进等等。有关自动迁移脚本和更多信息，请参阅 React 16.9 博客文章。

重大更改​

• 移除 React .xcodeproj。 在 0.60 中，我们通过 CocoaPods 引入了自动链接支持。我们还将 CocoaPods 集成到 e2e 测试运行中，因此从现在开始，我们有了一种统一的标准方式将 RN 集成到 iOS 应用中。这有效地弃用了 React .xcodeproj 支持，并且该文件已从 0.61 开始移除。注意：如果你已经使用 0.60 自动链接，则不应受到影响。

感谢​

感谢所有帮助 0.61 成为可能的贡献者！

要查看所有更新，请查看 0.61 更新日志。

上周在 Chain React 大会上，我们宣布了 Hermes，这是我们在 Facebook 开发的一个开源 JavaScript 引擎。它是一个小型轻量级的 JavaScript 引擎，专为在 Android 上运行 React Native 而优化。 查看一下！

Hermes 通过减少内存使用量、缩小下载大小以及缩短应用变得可用或“可交互时间”（TTI）的时间来提高 React Native 性能。

“当我们分析性能数据时，我们注意到 JavaScript 引擎本身是启动性能和下载大小的重要因素。有了这些数据，我们知道与桌面或笔记本电脑相比，我们必须在移动电话的更受限环境中优化 JavaScript 性能。在探索了其他选项之后，我们构建了一个新的 JavaScript 引擎，我们称之为 Hermes。它旨在提高应用性能，专注于我们的 React Native 应用，即使是在内存有限、存储速度慢和计算能力降低的大众市场设备上。” ——Hermes：一个为移动应用优化的开源 JavaScript 引擎，从 React Native 开始

想立即开始使用吗？请务必查看我们在文档中关于在现有 React Native 应用中启用 Hermes 的新指南！

Rachel Nabors 插画

经过数百位贡献者数月的辛勤工作，React Native 核心团队自豪地宣布发布 0.60 版本。此版本处理了 Android 和 iOS 平台的重大迁移，并且还解决了许多问题。这篇博客文章涵盖了此版本的亮点。但与往常一样，请参阅更新日志以获取更详细的信息。最后，感谢各位贡献者帮助我们实现这个里程碑！

关注无障碍功能​

无障碍功能 API 进行了许多改进，例如 announceForAccessibility，以及对 roles、action support、flags 等的改进。无障碍功能是一门复杂的科学，但我们希望这些改进能让 A11Y 更容易实现。请务必查看 React Native 开源更新 2019 年 6 月，了解这些更改的更多详细信息。

全新的开始​

React Native 的启动屏幕已更新！感谢众多贡献者帮助创建了新的 UI。这个新的“Hello World”将以更友好、更吸引人的方式欢迎用户进入生态系统。

AndroidX 支持​

AndroidX 是 Android 生态系统向前迈出的重要一步，旧的支持库工件正在被弃用。对于 0.60，React Native 已迁移到 AndroidX。这是一个重大更改，你的原生代码和依赖项也需要迁移。

随着此更改，React Native 应用本身将需要开始使用 AndroidX。它们不能在一个应用中并排使用，因此所有应用代码和依赖项代码都需要使用其中一个。

matt-oakes 在 discussions-and-proposals 上的评论

虽然你自己的原生代码需要你自行迁移，但 @mikehardy、@cawfree 和 @m4tt72 构建了一个 名为“jetifier”的巧妙工具 来修补你的 node_modules。库维护者将需要升级，但此工具为你提供了一个临时解决方案，同时让他们有时间发布 AndroidX 版本。因此，如果你发现与 AndroidX 迁移相关的错误，请尝试一下。

默认使用 CocoaPods​

CocoaPods 现在是 React Native iOS 项目的一部分。如果你还没有这样做，请务必从现在开始使用 xcworkspace 文件打开 iOS 平台代码（提示：从根项目目录尝试 xed ios）。此外，内部包的 podspec 已更改，以使其与 Xcode 项目兼容，这将有助于故障排除和调试。预计在升级到 0.60 时，你需要对你的 Podfile 进行一些简单的更改，以引入此令人兴奋的支持。请注意，我们意识到与 use_frameworks! 存在兼容性问题，并且我们正在跟踪一个问题，其中包含解决方法和未来的补丁。

精简核心移除​

WebView 和 NetInfo 之前已提取到单独的存储库中，在 0.60 中，我们已完成将它们从 React Native 存储库中迁移出来。此外，为了响应社区对新的 App Store 政策的反馈，Geolocation 也已被提取。如果你尚未完成迁移，请通过添加依赖项到 react-native-webview、@react-native-community/netinfo 和 @react-native-community/geolocation 来完成迁移。如果你想要自动化的解决方案，请考虑使用 rn-upgrade-deprecated-modules。自提取以来，维护者已向这些存储库提交了 100 多个 commit，我们很高兴看到社区的支持！

原生模块现在自动链接​

致力于 React Native CLI 的团队对原生模块链接引入了重大改进，称为 自动链接！大多数情况下，将不再需要使用 react-native link。同时，该团队全面改进了链接过程。请务必如上述文档中所述，react-native unlink 任何预先存在的依赖项。

升级助手​

@lucasbento、@pvinis、@kelset 和 @watadarkstar 构建了一个名为 Upgrade Helper 的出色工具，使升级过程更简单。它可以帮助具有棕地应用或复杂自定义的 React Native 用户查看版本之间的更改。查看更新的升级文档，并立即为你的升级路径试用一下！

给库维护者的注意事项​

AndroidX 的更改几乎肯定需要更新你的库，因此请务必尽快包含支持。如果你还无法升级，请考虑针对 jetifier 检查你的库，以确认用户可以在构建时修补你的库。

查看 自动链接 文档以更新你的配置和 readme。根据你之前集成库的方式，你可能还需要进行一些额外的更改。查看 CLI 中的 dependencies 指南，了解如何定义你的依赖项接口。

感谢​

虽然这些是我们注意到的亮点，但还有许多其他令人兴奋的内容。要查看所有更新，请查看 更新日志。与往常一样，请继续关注更多新闻。同时享受 0.60 吧！

代码和社区健康状况​

在过去六个月中，超过 550 位贡献者向 React Native 提交了总共 2800 个 commit。来自社区的 400 位贡献者创建了超过 1,150 个 Pull Request，其中 820 个 Pull Request 已合并。

过去六个月中，平均每天的 Pull Request 数量从三个增加到大约六个，即使我们通过精简核心工作将网站、CLI 和许多模块从 React Native 中分离出来。当前未完成的 pull request 的平均数量低于 25 个，我们通常会在数小时或数天内回复建议和评论。

有意义的社区贡献​

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

• 无障碍功能： React Native 0.60 将发布许多对 Android 和 iOS 上的无障碍功能 API 的改进。所有新功能都直接使用底层平台提供的 API，因此它们将与 Android 和 iOS 上的原生辅助技术集成。我们要感谢 Marc Mulcahy、Alan Kenyon、Estevão Lucas、Sam Mathias Weggersen 和 Janic Duplessis 的贡献
  • 额外的无障碍功能角色 + 状态 和 新的无障碍功能状态 API。为各种组件添加了许多缺失的无障碍功能角色，并为将来更好地支持 Web 添加了新的 API。
  • AccessibilityInfo.announceForAccessibility。添加了对 Android 的支持，以前仅限 iOS。
  • 扩展的无障碍功能操作支持。添加了回调以处理围绕用户定义操作的无障碍功能。
  • 对 iOS 无障碍功能标志的支持 和 对“reduce motion”的支持。
  • Android 键盘无障碍功能改进。为通过键盘导航调用操作添加了 clickable 属性和一个 onClick 回调 （注意：这很快将重命名为 focusable）。
  • 使用 CALayer 绘制文本。修复了在 iOS 上缩放文本会消失的问题。
• 新的应用屏幕： 社区提出了 新应用屏幕的设计，该设计已在 0.60 中实现。此屏幕是大多数人在首次使用 React Native 时看到的屏幕。现在，它将首次用户链接到文档，并且外观与我们即将推出的网站重新设计相符 🌟。非常感谢 Orta、Adam Shurson、Glauber Castro、Karan Singh、Eli Perkins、Lucas Bento 和 Eric Lewis 的所有工作和协作！
  • 在 “React Native Show“ 视频系列中查看新的应用屏幕。
• TurboModule 类型： 新的 TurboModules 系统 需要 所有原生模块的类型，以保证原生类型安全操作。在仅仅两周多的时间里，社区发送了约 40 个 Pull Request 来完成这项针对 flow 类型化的原生模块的工作。除了上面已经提到的人之外，我们还要感谢 Michał Chudziak、Michał Pierzchała、Wojtek Szafraniec 和 Jean Regisser 以及其他所有发送了一个或多个 Pull Request 的人。
• Haste： 自 2015 年以来，React Native 使用了 “haste”模块系统，该系统允许仅通过全局 ID 而不是相对路径导入模块，这很方便，但许多工具不支持。James Ide 建议移除 haste，类似于 React 多年前移除 haste 的方式。他通过 总括任务 计划了所有工作，并发送了 18 个 Pull Request 使其实现！查看 他的 Twitter 帖子 了解更多信息。
• Android Fragments： John Shelley 的关于使 React Native 通过 Android Fragments 工作的提案已合并，将在 0.61 中可用。 在此处阅读有关 Android Fragments 的更多信息。

精简核心​

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

我们还借此机会从 React Native 本身中移除了过时的 polyfill 和遗留组件。过去需要 polyfill 来支持旧版本 JavaScriptCore (JSC) 中的 Map 和 Set 等语言功能。现在 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 社区团结一致，对升级体验进行了多项改进：自动链接、通过 rn-diff-purge 改进的升级命令、升级助手网站（即将推出）。我们还将确保通过发布每个主要版本的博客文章来沟通重大更改和令人兴奋的新功能。许多这些改进将使未来 0.60 版本之后的升级变得更加容易。
• 支持/不确定性： 许多人对 Pull Request 的缺乏活动以及对 Facebook 在 React Native 中的投资的普遍不确定性感到沮丧。正如我们在上面展示的那样，我们可以自信地说，我们已准备好接受更多 Pull Request，并且我们热切期待你的提案和贡献！
• 性能： React Native 0.59 附带了 JavaScriptCore (JSC) 的新版本，速度更快得多。另外，我们一直在努力使其更容易默认启用 inline-requires，并且在接下来的几个月中，我们将为你带来更令人兴奋的更新。
• 文档： 我们最近开始努力 全面修订和重写所有 React Native 的文档。如果你正在寻找贡献方式，我们很乐意得到你的帮助！
• Xcode 中的警告： 我们 摆脱了所有现有的警告，并努力不引入新的警告。
• 热重载： React 团队正在构建一个新的热重载系统，该系统将很快集成到 React Native 中。

不幸的是，我们还无法立即改进所有方面

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

鉴于过去六个月中进行了大量更改，我们想再次向您提出同样的问题。如果您正在使用最新版本的 React Native，并且您有想要提供反馈的内容，请在我们的新版“您对 React Native 有什么不满？”中发表评论。

持续集成​

Facebook 首先将所有 Pull Request 和内部更改直接合并到 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 React 和 React Native EU 上发表演讲。此外，请留意我们即将发布的 0.60 版本，它即将到来。这将令人兴奋 ✨

本周，Eli White 在 F8 2019 上发表了关于 React Native 在 Facebook 的 Android 和 iOS 应用程序中的应用的演讲。我们很高兴分享我们在过去两年中所做的工作以及我们接下来的计划。

在 Facebook 的开发者网站上查看视频

演讲亮点：​

• 我们在 2017 年和 2018 年专注于 React Native 的最大产品 Facebook Marketplace。我们与 Marketplace 团队合作，以提高产品质量并增加用户愉悦感。目前，Marketplace 是 Facebook 应用程序中 Android 和 iOS 平台上质量最高的产品之一。
• Marketplace 的性能也是一个巨大的挑战，尤其是在中端 Android 设备上。在过去一年中，我们将启动时间缩短了 50% 以上，并且还在进行更多改进！最大的改进正在构建到 React Native 中，并将于今年晚些时候提供给社区。
• 我们有信心可以使用 React Native 构建 Facebook 所需的高质量和高性能应用程序。这种信心使我们能够在更大的方面进行投资，例如重新思考 React Native 的核心。
• Microsoft 支持并将 React Native 用于 Windows，使人们能够使用他们的专业知识和代码库来渲染到 Microsoft 的通用 Windows 平台。查看下周的 Microsoft Build，听取他们更多地谈论这一点。

关于开源的 React Radio Podcast​

Eli 的演讲最后谈到了我们最近的开源工作。我们在三月份发布了关于我们进展的更新，最近 Nader Dabit 和 Gant Laborde 邀请 Christoph 参加了他们的播客 React Native Radio 的聊天，讨论 React Native 在开源中的应用。

播客的亮点：​

• 我们讨论了 Facebook 的 React Native 团队如何看待开源，以及我们如何为一个像 React Native 这样规模的项目构建一个可持续的社区。
• 我们正在按计划移除多个模块，作为 Lean Core 工作的一部分。自提取以来，WebView 和 React Native CLI 等许多模块已收到 100 多个 Pull Request。
• 接下来，我们将专注于全面改进 React Native 网站和文档。敬请期待！

您很快将在您最喜欢的播客应用程序中找到该集，或者您可以在这里收听录音

欢迎来到 React Native 0.59 版本！这是又一个重要的版本，包含 88 位贡献者的 644 次提交。贡献也以其他形式出现，因此感谢您维护问题、培育社区以及向人们传授 React Native 的知识。本月带来了一些备受期待的更改，我们希望您喜欢它们。

🎣 Hooks 来了​

React Hooks 是此版本的一部分，它允许您在组件之间重用有状态逻辑。关于 hooks 有很多讨论，但如果您还没有听说过，请查看下面的一些精彩资源

• Introducing Hooks 解释了我们为什么要向 React 添加 Hooks。
• Hooks at a Glance 是对内置 Hooks 的快速概述。
• Building Your Own Hooks 演示了如何使用自定义 Hooks 进行代码重用。
• Making Sense of React Hooks 探索了 Hooks 释放的新可能性。
• useHooks.com 展示了社区维护的 Hooks 食谱和演示。

请务必在您的应用程序中尝试一下。我们希望您像我们一样对重用感到兴奋。

📱 更新的 JSC 意味着性能提升和 Android 上的 64 位支持​

React Native 使用 JSC (JavaScriptCore) 来驱动您的应用程序。Android 上的 JSC 已经有几年历史了，这意味着许多现代 JavaScript 功能都不受支持。更糟糕的是，与 iOS 的现代 JSC 相比，它的性能很差。随着此版本的发布，这一切都改变了。

感谢 @DanielZlotin、@dulmandakh、@gengjiawen、@kmagiera 和 @kudo 的出色工作，JSC 已经赶上了过去几年的发展。这带来了 64 位支持、现代 JavaScript 支持和巨大的性能改进。感谢他们使这成为一个可维护的过程，以便我们能够利用未来的 WebKit 改进，而无需进行如此多的前期工作，并感谢 Software Mansion 和 Expo 使这项工作成为可能。

💨 使用内联 require 更快地启动应用程序​

我们希望帮助人们默认拥有高性能的 React Native 应用程序，并且正在努力将 Facebook 的优化措施引入社区。应用程序在需要时加载资源，而不是减慢启动速度。此功能称为“内联 require”，因为它允许 Metro 识别要延迟加载的组件。具有深度和多样化组件架构的应用程序将看到最大的改进。

我们需要社区告知我们它的工作原理，然后我们才能默认启用它。当您升级到 0.59 时，将有一个新的 metro.config.js 文件；将选项翻转为 true，并向我们提供您的反馈！阅读更多关于内联 require 的信息，请访问性能文档以基准测试您的应用程序。

🚅 Lean core 正在进行中​

React Native 是一个庞大而复杂的项目，代码仓库也很复杂。这使得代码库对贡献者来说不太容易接近，难以测试，并且作为开发依赖项显得臃肿。Lean Core 是我们为解决这些问题而做出的努力，通过将代码迁移到单独的库中以进行更好的管理。在过去的几个版本中，我们已经看到了这方面的初步进展，但让我们认真对待。

您可能会注意到，其他组件现在已被正式弃用。这是一个好消息，因为现在有这些功能的维护者积极维护它们。请注意警告消息，并将这些功能迁移到新的库，因为它们将在未来的版本中被删除。下表指示了组件、其状态以及您可以迁移到的新位置。

在接下来的几个月中，将有更多组件遵循这条道路，走向更精简的核心。我们正在寻求帮助——前往lean core umbrella参与其中。

👩🏽‍💻 CLI 改进​

React Native 的命令行工具是开发人员进入生态系统的入口点，但它们长期存在问题并且缺乏官方支持。CLI 工具已迁移到新的代码仓库，并且一个专门的维护者团队已经做出了一些令人兴奋的改进。

日志现在的格式更好。命令现在几乎可以立即运行——您会立即注意到差异

🚀 升级到 0.59​

我们听取了您关于 React Native 升级过程的反馈，并且正在采取措施在未来的版本中改进体验。要升级到 0.59，我们建议使用 rn-diff-purge 来确定您当前的 React Native 版本和 0.59 之间发生了哪些更改，然后手动应用这些更改。一旦您将项目升级到 0.59，您将能够使用新改进的 react-native upgrade 命令（基于 rn-diff-purge！）升级到 0.60 及更高版本，随着新版本的发布。

🔨 破坏性更改​

0.59 中的 Android 支持已根据 Google 的最新建议进行了清理，这可能会导致现有应用程序的潜在破坏。此问题可能会表现为运行时崩溃和消息“您需要将 Theme.AppCompat 主题（或后代）与此 activity 一起使用”。我们建议更新项目的 AndroidManifest.xml 文件，确保 android:theme 值是 AppCompat 主题（例如 @style/Theme.AppCompat.Light.NoActionBar）。

react-native-git-upgrade 命令已在 0.59 中删除，取而代之的是新改进的 react-native upgrade 命令。

🤗 感谢​

许多新的贡献者帮助从 flow 类型生成原生代码和解决 Xcode 警告 - 这些是了解 React Native 如何工作并为更大的利益做出贡献的好方法。谢谢！请留意未来类似的问题。

虽然这些是我们注意到的亮点，但还有许多其他方面令人兴奋。要查看所有更新，请查看更新日志。0.59 是一个巨大的版本——我们迫不及待想让您试用它。

我们在今年余下的时间里还有更多改进即将推出。敬请期待！

Ryan 和整个 React Native 核心团队

我们宣布了我们在 2018 年第四季度的React Native 开源路线图，在决定加大对 React Native 开源社区的投入之后。

对于我们的第一个里程碑，我们专注于识别和改进我们社区最明显的方面。我们的目标是减少未完成的 pull request，缩小项目的表面积，识别主要用户问题，并建立社区管理指南。

在过去的两个月中，我们取得的进展超出了预期。继续阅读以了解更多详情

Pull Requests​

为了构建一个健康的社区，我们必须快速响应代码贡献。在过去的几年中，我们降低了审查社区贡献的优先级，并积累了 280 个 pull request（2018 年 12 月）。在第一个里程碑中，我们将未完成的 pull request 数量减少到约 65 个。与此同时，每天打开的 pull request 平均数量从 3.5 个增加到 7 个，这意味着我们在过去三个月中处理了大约 600 个 pull request。

我们合并了 近三分之二，并关闭了三分之一的 pull request。如果它们过时或质量不高，或者如果它们不必要地增加了项目的表面积，则在未合并的情况下关闭它们。大多数合并的 pull request 修复了错误，改进了跨平台奇偶校验，或引入了新功能。值得注意的贡献包括改进类型安全性和正在进行的 AndroidX 支持工作。

在 Facebook，我们从 master 分支运行 React Native，因此我们在所有更改进入 React Native 版本之前首先对其进行测试。在所有合并的 pull request 中，只有六个引起了问题：四个仅影响内部开发，两个在候选发布状态下被捕获。

更可见的社区贡献之一是更新的“RedBox”屏幕。这是社区如何使开发人员体验更友好的一个很好的例子。

精简核心​

React Native 目前具有非常广泛的表面积，其中许多未维护的抽象概念我们在 Facebook 中使用不多。我们正在努力缩小表面积，以使 React Native 更小，并允许社区更好地照顾 Facebook 中主要未使用的抽象概念。

在第一个里程碑中，我们请求社区帮助进行 Lean Core 项目。反应非常热烈，我们几乎无法跟上所有进展。查看在一个月内完成的所有工作！

我们最兴奋的是维护人员已经开始修复长期存在的问题，添加测试并支持长期请求的功能。这些模块获得的支持比以往在 React Native 中获得的更多，这表明这对社区来说是一个伟大的进步。此类项目的示例包括 WebView，自从提取以来，它已经收到了许多 pull request，以及现在由社区成员维护并获得了急需的改进和修复的 CLI。

主要用户问题​

在 12 月，我们询问社区他们对 React Native 有什么不满。我们汇总了回复，并回复了每一个问题。幸运的是，我们的社区面临的许多问题也是 Facebook 的问题。在我们的下一个里程碑中，我们计划解决一些主要问题。

投票最多的问题之一是升级到较新版本的 React Native 的开发者体验。不幸的是，这不是我们自己会遇到的事情，因为我们从 master 分支运行 React Native。值得庆幸的是，社区成员已经站出来解决这个问题

• 来自 Callstack 的 Michał Pierzchała 通过在底层使用 rn-diff-purge 改进了 react-native upgrade。我们还更新了网站以删除过时的升级说明。
• 我们计划默认推荐 CocoaPods 用于 iOS 项目，这将减少升级 React Native 时项目文件的变动。这将使人们更容易安装和链接第三方模块，这在 Lean Core 的背景下甚至更重要，因为我们预计项目默认情况下会链接更多模块。

0.59 版本​

如果没有 React Native 社区（尤其是 Mike Grabowski 和 Lorenzo Sciandra）的帮助，我们将无法发布版本。我们希望改进发布管理流程，并计划从现在开始更多地参与其中

• 我们将与社区成员合作，为每个主要版本创建一篇博客文章。
• 当人们升级到新版本时，我们将在 CLI 中直接显示破坏性更改。
• 我们将减少发布版本所需的时间。我们正在探索增加自动化测试的方法，并创建一个改进的手动测试计划。

许多这些计划将纳入即将发布的 React Native 0.59 版本。0.59 将附带 React Hooks、适用于 Android 的新的 64 位 JavaScriptCore 版本以及许多性能和功能改进。它目前作为候选发布版本发布，预计在未来两周内稳定。

下一步​

在接下来的两个月中，我们将继续管理 pull request 以保持进度，同时开始减少未解决的 GitHub issue 的数量。我们将继续通过 Lean Core 项目来缩小 React Native 的表面积。我们计划解决社区最关心的 5 个问题。在我们最终确定社区指南后，我们将把注意力转向我们的网站和文档。

我们非常高兴在三月份在 Facebook 伦敦接待来自我们社区的十多位贡献者，以帮助推动其中几项工作。我们很高兴您正在使用 React Native，并希望您会看到和感受到我们在 2019 年正在进行的改进。我们将在几个月后再次发布更新，并且在此期间将合并您的 pull request！ ⚛️✌️

在 2018 年，React Native 社区对我们开发和沟通 React Native 的方式进行了一些更改。我们相信，几年后，当我们回顾过去时，会发现这种转变是 React Native 的转折点。

很多人对 React Native 架构的重写感到兴奋，这被广泛称为 Fabric。除此之外，这将修复 React Native 架构中的基本限制，并将为 React Native 未来的成功奠定基础，同时还有 JSI 和 TurboModules。

2018 年最大的转变是赋予 React Native 社区权力。从一开始，Facebook 就鼓励来自世界各地的开发人员参与 React Native 的开源项目。从那时起，涌现出许多核心贡献者来处理发布过程等事务。

这些成员采取了一些实质性步骤，通过以下资源使整个社区更有能力塑造该项目的未来

react-native-releases 📬​

该代码仓库创建于 1 月份，具有双重目的，既允许每个人以更协作的方式跟上新版本的发布，又开放了关于某个版本中将包含哪些内容以及谁想建议 cherry-pick（例如 0.57.8 及其所有先前版本）的对话。

这是推动我们摆脱每月发布周期以及当前用于 0.57.x 版本的“长期支持”方法的驱动力。

达到这些决定的功劳一半归功于今年创建的另一个代码仓库

discussions-and-proposals 🗣​

该代码仓库创建于 7 月份，扩展了关于 React Native 对话的更开放环境的想法。以前，这种需求由主代码仓库中标记为 For Discussion 的 issue 处理，但我们希望将此策略扩展到其他库（例如 React）拥有的 RFC 方法。

该实验立即找到了其在 React Native 生命周期中的作用。Facebook 团队现在正在使用社区 RFC 流程来讨论可以在 React Native 中改进的内容，并协调围绕 Lean Core 项目的努力——以及其他有趣的讨论。

@ReactNativeComm 🐣​

我们意识到我们沟通这些努力的方式并没有我们希望的那么有效，并且为了让您更容易跟上 React Native 社区中发生的一切（从发布到积极的讨论），我们创建了一个新的 Twitter 帐户，您可以依靠 @ReactNativeComm。

如果您不在该社交网络上，请记住您始终可以通过 GitHub 关注代码仓库；此功能在过去几个月中得到了改进，可以仅针对版本发布接收通知，因此您无论如何都应该考虑使用它。

未来的展望 🎓​

在过去的 7-8 个月中，核心贡献者增强了 React Native Community GitHub 组织，以在 React Native 的开发中承担更多责任，并加强与 Facebook 的协作。但这始终缺乏类似项目可能拥有的正式结构。

该组织可以为更大的开发者社区中的每个人树立榜样，通过对托管在其中的所有软件包/代码仓库强制执行一套标准，为维护者提供一个相互帮助和贡献符合社区约定标准的高质量代码的统一场所。

在 2019 年初，我们将制定这套新的指导方针。请在专门的讨论中告诉我们您的想法。

我们相信，通过这些更改，社区将变得更具协作性，以便当我们达到 1.0 版本时，我们将继续通过利用这种共同努力来编写（更多）出色的应用程序 🤗

我希望您像我们一样对这个社区的未来感到兴奋。我们很高兴看到你们所有人都参与到上面列出的代码仓库中正在进行的对话中，或者通过你们将生成的出色代码参与其中。

编码愉快！

今年，React Native 团队专注于大规模的 React Native 架构重构。正如 Sophie 在她的React Native 2018 年状态帖子中提到的那样，我们已经草拟了一个计划，以更好地支持 Facebook 以外蓬勃发展的 React Native 用户和协作者群体。现在是时候分享更多关于我们一直在做的工作的细节了。在这样做之前，我想阐述一下我们对开源 React Native 的长期愿景。

我们对 React Native 的愿景是...

• 一个健康的 GitHub 代码仓库。 Issue 和 pull request 在合理的时间段内得到处理。
  • 增加测试覆盖率。
  • 从 Facebook 代码仓库同步出来的提交不应破坏开源测试。
  • 更大规模的有意义的社区贡献。
• 稳定的 API， 使与开源依赖项的接口更容易。
  • Facebook 使用与开源相同的公共 API
  • 遵循语义版本控制的 React Native 版本。
• 一个充满活力的生态系统。 由社区维护的高质量 ViewManager、原生模块和多平台支持。
• 优秀的文档。 专注于帮助用户创建高质量的体验，以及最新的 API 参考文档。

我们已经确定了以下重点领域，以帮助我们实现这一愿景。

✂️ Lean Core​

我们的目标是通过删除非核心和未使用的组件来缩小 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 上更好地测试核心代码库，从而使未来的 pull request 能够轻松地包含测试。

结合缩减的表面积，这将使贡献者能够更快、更自信地合并 pull request。

📜 公共 API​

Facebook 将像开源社区一样，通过公共 API 使用 React Native，以减少意外的破坏性更改。我们已经开始转换内部调用站点以解决这个问题。我们的目标是形成一个稳定的公共 API，最终在 1.0 版本中采用语义化版本控制。

📣 沟通​

React Native 是 GitHub 上贡献者数量最多的 顶级开源项目之一。这让我们感到非常高兴，我们希望继续保持下去。我们将继续努力推进能够吸引更多贡献者的举措，例如提高透明度和公开讨论。文档是新接触 React Native 的人最先接触到的内容之一，但它一直没有成为优先事项。我们希望解决这个问题，首先是恢复自动生成的 API 参考文档，创建更多专注于创建高质量用户体验的内容，并改进我们的发行说明。

时间线​

我们计划在未来一年左右的时间内完成这些项目。其中一些工作已经在进行中，例如 JSI 已经发布到开源社区。其他一些项目则需要更长的时间才能完成，例如缩减表面积。我们将尽最大努力让社区及时了解我们的进展。请加入我们的 Discussions and Proposals 仓库，这是 React Native 社区发起的一项倡议，促成了本路线图中讨论的若干项举措。