欢迎来到 React Native 的 0.59 版本！这是一个重要的版本，包含 88 位贡献者的 644 次提交。贡献也以其他形式存在，所以**感谢您**维护问题、培养社区并向人们教授 React Native。本月带来了一些备受期待的变化，我们希望您会喜欢它们。

🎣 Hooks 来了​

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

• Hooks 简介解释了我们为什么要在 React 中添加 Hooks。
• Hooks 概述是内置 Hooks 的快速概览。
• 构建自己的 Hooks演示了自定义 Hooks 的代码重用。
• 理解 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 的更多信息以基准测试您的应用。

🚅 精益核心正在进行中​

React Native 是一个庞大而复杂的项目，拥有复杂的代码库。这使得代码库对贡献者而言更难接近，更难以测试，并且作为开发依赖项而言过于臃肿。精益核心是我们通过将代码迁移到单独的库以实现更好管理来解决这些问题的努力。过去几个版本已经迈出了第一步，但让我们认真起来。

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

在接下来的几个月里，将有更多组件遵循这条路径走向更精益的核心。我们正在寻求这方面的帮助——请前往精益核心总览贡献一份力量。

👩🏽‍💻 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 主题（或其子孙）与此活动一起使用”。我们建议更新您项目的 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 核心团队

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

我们的第一个里程碑，我们专注于识别和改进社区最显著的方面。我们的目标是减少未处理的拉取请求，减少项目的表面积，识别主要的用户问题，并建立社区管理准则。

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

拉取请求​

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

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

在 Facebook，我们从 master 运行 React Native，因此我们在将所有更改发布到 React Native Release 之前先进行测试。在所有合并的拉取请求中，只有六个引起了问题：四个只影响内部开发，两个在发布候选状态下被发现。

一项更引人注目的社区贡献是更新后的“RedBox”屏幕。这是一个很好的例子，说明社区如何使开发人员体验更友好。

精益核心​

React Native 目前有一个非常广泛的表面积，其中有许多我们 Facebook 不怎么使用的未维护的抽象。我们正在努力减少表面积，以使 React Native 更小，并允许社区更好地维护那些在 Facebook 很少使用的抽象。

在第一个里程碑中，我们向社区寻求精益核心项目的帮助。反响非常热烈，我们几乎跟不上所有的进展。查看不到一个月内完成的所有工作！

我们最兴奋的是，维护者们已经开始修复长期存在的问题，添加测试，并支持长期请求的功能。这些模块现在获得了比在 React Native 中更多的支持，这表明这是社区迈出的重要一步。此类项目的一些示例是 WebView，自其提取以来收到了许多拉取请求，以及现在由社区成员维护的 CLI，并获得了急需的改进和修复。

主要用户问题​

去年12月，我们询问社区他们不喜欢 React Native 的哪些方面。我们汇总了回复，并逐一回复了所有问题。幸运的是，我们的社区面临的许多问题也是 Facebook 的问题。在下一个里程碑中，我们计划解决一些主要问题。

投票最高的问题之一是将 React Native 升级到新版本的开发体验。不幸的是，这不是我们自己会遇到的问题，因为我们从 master 运行 React Native。值得庆幸的是，社区成员已经主动解决了这个问题

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

0.59 版本发布​

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

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

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

下一步​

在接下来的两个月里，我们将继续管理拉取请求，以保持进度，同时开始减少未解决的 GitHub 问题数量。我们将通过精益核心项目继续缩小 React Native 的表面积。我们计划解决 5 个主要的社区问题。在最终确定社区准则后，我们将把注意力转向我们的网站和文档。

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

2018 年，React Native 社区在开发和沟通 React Native 的方式上做出了一些改变。我们相信几年后，我们会回顾并发现这次转变是 React Native 的一个转折点。

很多人对 React Native 架构的重写感到兴奋，这通常被称为 Fabric。除此之外，这将解决 React Native 架构中的根本限制，并与 JSI 和 TurboModules 一起为 React Native 未来的成功奠定基础。

2018 年最大的转变是赋能 React Native 社区。从一开始，Facebook 就鼓励世界各地的开发者参与 React Native 的开源项目。此后，一些核心贡献者出现，负责处理发布过程等。

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

react-native-releases 📬​

这个于一月创建的仓库有两个目的：允许所有人以更协作的方式跟上新版本，并向任何想提出精选（例如 0.57.8 及其所有早期版本）的人开放特定版本内容的讨论。

这是推动月度发布周期转变以及当前用于 0.57.x 版本的“长期支持”方法背后的驱动力。

达成这些决策的一半功劳归功于今年创建的另一个仓库

discussions-and-proposals 🗣​

这个于七月创建的仓库，扩展了 React Native 开放讨论环境的理念。以前，这种需求通过主仓库中标记为 For Discussion 的问题来处理，但我们希望将这种策略扩展到其他库（例如 React）采用的 RFC 方法。

这个实验立即在 React Native 生命周期中找到了它的作用。Facebook 团队现在正在使用社区 RFC 流程来讨论React Native 可以改进什么，并协调围绕精益核心项目的努力——以及其他有趣的讨论。

@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 仓库。 问题和拉取请求在合理的时间内得到处理。
  • 增加测试覆盖率。
  • 从 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 社区的一项倡议，它促成了本路线图中讨论的几项倡议的创建。

很长一段时间以来，Apple 一直不鼓励使用 UIWebView，而倾向于 WKWebView。在 iOS 12（将在未来几个月发布）中，UIWebView 将被正式弃用。React Native 的 iOS WebView 实现严重依赖 UIWebView 类。因此，鉴于这些发展，我们为 WebView React Native 组件构建了一个新的原生 iOS 后端，它使用 WKWebView。

这些更改的最后部分已在此提交中落地，并将随0.57版本发布。

要选择此新实现，请使用useWebKit prop。

<WebView
  useWebKit={true}
  source={{url: 'https://www.google.com'}}
/>

改进​

UIWebView 没有合法的方式来促进 WebView 中运行的 JavaScript 与 React Native 之间的通信。当从 WebView 发送消息时，我们依赖于一个 hack 来将它们传递给 React Native。简单来说，我们将消息数据编码到一个具有特殊方案的 URL 中，并将 WebView 导航到该 URL。在原生端，我们拦截并取消了此导航，从 URL 中解析出数据，最后调用 React Native。这种实现容易出错且不安全。我很高兴地宣布，我们利用 WKWebView 功能完全取代了它。

WKWebView 相对于 UIWebView 的其他优势包括更快的 JavaScript 执行和多进程架构。有关更多详细信息，请参阅此2014 年 WWDC。

注意事项​

如果您的组件使用以下属性，那么在切换到WKWebView时可能会遇到问题。目前，我们建议您避免使用这些属性

不一致的行为

automaticallyAdjustContentInsets 和 contentInsets (提交)

当您向 WKWebView 添加 contentInsets 时，它不会更改 WKWebView 的视口。视口大小与帧保持相同。使用 UIWebView，视口大小实际上会改变（如果 content insets 为正，则会变小）。

backgroundColor (提交)

使用 WebView 的新 iOS 实现，如果您使用此属性，您的背景颜色可能会闪烁。此外，WKWebView 对透明背景的渲染方式与 UIWebView 不同。请参阅提交说明了解更多详细信息。

不支持

scalesPageToFit (提交)

WKWebView 不支持 `scalesPageToFit` 属性，因此我们无法在 WebView React Native 组件中实现此功能。

动机​

随着技术的进步和移动应用在日常生活中变得越来越重要，创建无障碍应用的需求也同样变得越来越重要。

React Native有限的无障碍API一直是开发人员的一大痛点，因此我们对无障碍API进行了一些更新，使其更容易创建包容性移动应用。

现有API的问题​

问题一：两个完全不同但相似的属性——accessibilityComponentType（Android）和 accessibilityTraits（iOS）​

accessibilityComponentType 和 accessibilityTraits 是两个属性，用于告知 Android 上的 TalkBack 和 iOS 上的 VoiceOver 用户正在与哪种 UI 元素进行交互。这两个属性最大的问题在于

1. 它们是两个具有不同使用方法的不同属性，但目的相同。在之前的 API 中，它们是两个独立的属性（每个平台一个），这不仅不方便，而且让许多开发人员感到困惑。iOS 上的 accessibilityTraits 允许 17 种不同的值，而 Android 上的 accessibilityComponentType 只允许 4 种值。此外，这些值大部分没有重叠。甚至这两个属性的输入类型也不同。accessibilityTraits 允许传入一个特性数组或单个特性，而 accessibilityComponentType 只允许单个值。
2. Android上的功能非常有限。使用旧属性，Talkback 唯一能识别的 UI 元素是“按钮”、“单选按钮已选中”和“单选按钮未选中”。

问题二：不存在的无障碍提示：​

无障碍提示帮助使用 TalkBack 或 VoiceOver 的用户了解当他们在无障碍元素上执行操作时会发生什么，这些信息仅凭无障碍标签并不明显。这些提示可以在设置面板中打开和关闭。以前，React Native 的 API 完全不支持无障碍提示。

问题三：忽略反转颜色：​

一些视力受损的用户会使用手机上的反色功能来增加屏幕对比度。苹果为 iOS 提供了一个 API，允许开发者忽略某些视图。这样，当用户开启反色设置时，图像和视频就不会失真。React Native 目前不支持此 API。

新API的设计​

解决方案一：合并 accessibilityComponentType (Android) 和 accessibilityTraits (iOS)​

为了解决 accessibilityComponentType 和 accessibilityTraits 之间的混淆，我们决定将它们合并为一个属性。这样做是有意义的，因为它们在技术上具有相同的预期功能，并且通过合并它们，开发人员在构建可访问性功能时不再需要担心平台特定的复杂性。

背景

在 iOS 上，UIAccessibilityTraits 是一个可以设置在任何 NSObject 上的属性。通过 JavaScript 属性传递到原生端的 17 个特性中的每一个都被映射到 Objective-C 中的一个 UIAccessibilityTraits 元素。特性都由一个长整型表示，并且所有设置的特性都进行 OR 运算。

然而，在 Android 上，AccessibilityComponentType 是 React Native 创造的一个概念，它不直接映射到 Android 中的任何属性。辅助功能由辅助功能委托处理。每个视图都有一个默认的辅助功能委托。如果您想自定义任何辅助功能操作，您必须创建一个新的辅助功能委托，覆盖您想要自定义的特定方法，然后将您正在处理的视图的辅助功能委托设置为与新委托关联。当开发人员设置 AccessibilityComponentType 时，原生代码根据传入的组件创建一个新的委托，并将视图设置为具有该辅助功能委托。

所做的更改

对于我们的新属性，我们希望创建两个属性的超集。我们决定将新属性主要建模为现有属性 accessibilityTraits，因为 accessibilityTraits 具有明显更多的值。Android 这些特性的功能将通过修改 Accessibility Delegate 来填充。

accessibilityTraits 在 iOS 上可以设置为 17 个 UIAccessibilityTraits 值。然而，我们并没有将所有这些值都包含在新属性的可能值中。这是因为设置其中一些特性的效果实际上并不为人所知，而且其中许多值几乎从未使用过。

UIAccessibilityTraits 的值通常有两种用途。它们要么描述 UI 元素所扮演的角色，要么描述 UI 元素所处的状态。我们观察到的大多数对先前属性的使用通常使用一个表示角色的值，并将其与“状态已选择”、“状态已禁用”或两者结合。因此，我们决定创建两个新的辅助功能属性：accessibilityRole 和 accessibilityState。

accessibilityRole

新属性accessibilityRole用于告诉Talkback或Voiceover UI元素的角色。此新属性可以取以下值之一

• 无
• 按钮
• 链接
• 搜索
• 图片
• 键盘键
• 文本
• 可调整
• 标题
• 总结
• 图片按钮

此属性只允许传入一个值，因为UI元素通常逻辑上不会承担其中多个角色。例外是图片和按钮，因此我们添加了一个组合两者的角色“图片按钮”。

辅助功能状态

新属性accessibilityStates用于告诉Talkback或Voiceover UI元素的状态。此属性接受一个包含以下一个或两个值的数组

• selected
• disabled

解决方案二：添加辅助功能提示​

为此，我们添加了一个新属性：accessibilityHint。设置此属性将允许Talkback或Voiceover向用户朗读提示。

accessibilityHint

此属性以字符串形式接收要读取的辅助功能提示。

在 iOS 上，设置此属性将设置视图上相应的原生属性 AccessibilityHint。如果 iPhone 中开启了辅助功能提示，则 Voiceover 将朗读该提示。

在 Android 上，设置此属性会将提示的值附加到辅助功能标签的末尾。此实现的好处是它模仿了 iOS 上提示的行为，但缺点是这些提示不能像 iOS 上那样在 Android 的设置中关闭。

我们在Android上做出这个决定的原因是，通常情况下，辅助功能提示与特定动作（例如，点击）相关联，我们希望在不同平台之间保持行为一致。

问题三的解决方案​

accessibilityIgnoresInvertColors

我们已将 Apple 的 API `AccessibilityIgnoresInvertColors` 暴露给 JavaScript，因此现在当您有一个不想反转颜色的视图（例如图片）时，您可以将此属性设置为 true，它就不会被反转。

新用法​

这些新属性将在React Native 0.57版本中可用。

如何升级​

如果您当前正在使用accessibilityComponentType和accessibilityTraits，这里是您可以采取的步骤来升级到新属性。

1. 使用jscodeshift​

最简单的用例可以通过运行jscodeshift脚本来替换。

这个脚本替换了以下实例

accessibilityTraits=“trait”
accessibilityTraits={[“trait”]}

带有

accessibilityRole= “trait”

此脚本还删除了AccessibilityComponentType的实例（假设您在所有设置AccessibilityComponentType的地方都同时设置了AccessibilityTraits）。

2. 使用手动代码修改​

对于使用 AccessibilityTraits 且没有对应 AccessibilityRole 值的情况，以及将多个特性传递给 AccessibilityTraits 的情况，需要进行手动代码修改。

通常，

accessibilityTraits= {[“button”, “selected”]}

将被手动替换为

accessibilityRole=“button”
accessibilityStates={[“selected”]}

这些属性已经在 Facebook 的代码库中使用了。Facebook 的代码修改出奇地简单。jscodeshift 脚本修复了大约一半的实例，另一半是手动修复的。总的来说，整个过程花了不到几个小时。

希望您会发现更新后的API很有用！并请继续让应用程序无障碍！#包容

期待已久的 React Native 0.56 版本现已发布 🎉。这篇博客文章重点介绍了此新版本中引入的一些更改。我们还想借此机会解释自 3 月以来我们一直忙碌的原因。

破坏性变更的困境，或者说，“何时发布？”​

贡献者指南解释了所有对 React Native 的更改所经历的集成过程。该项目由许多不同的工具组成，需要协调和持续支持以确保一切正常运行。再加上为项目做出贡献的充满活力的开源社区，您将对这一切的令人费解的规模有所了解。

随着 React Native 的惊人普及，破坏性变更必须谨慎进行，并且流程不如我们所愿那样顺畅。我们决定跳过 4 月和 5 月的发布，以允许核心团队集成和测试一组新的破坏性变更。专门的社区沟通渠道在此过程中被使用，以确保 2018 年 6 月（0.56.0）发布版本对于那些耐心等待稳定版本的人来说尽可能无忧。

0.56.0 完美吗？不，就像所有软件一样：但我们已经达到了一个平衡点，即“等待更多稳定性”与“测试成功，我们可以继续前进”的权衡，我们觉得已经准备好发布了。此外，我们意识到在最终的 0.56.0 版本中，存在 一些 尚未 解决的 问题。大多数开发人员应该可以顺利升级到 0.56.0。对于那些被上述问题阻止的人，我们希望看到您参与我们的讨论，我们期待与您合作解决这些问题。

您可能会将 0.56.0 视为构建更稳定框架的基础：可能需要一到两周的广泛采用才能消除所有边缘情况，但这将导致 2018 年 7 月（0.57.0）版本更好。

我们想通过感谢总共提交了 818 次代码的 67 位贡献者，他们将帮助您的应用程序变得更好 👏。

现在，话不多说...

重大变更​

Babel 7​

如您所知，允许我们使用 JavaScript 最新和最强大功能的转译工具 Babel 即将发布v7 版本。由于这个新版本带来了一些重要的变化，我们觉得现在是升级的好时机，这将允许 Metro 利用其改进。

如果您在升级时遇到问题，请参阅相关的文档部分。

现代化 Android 支持​

在 Android 上，许多周边工具都已更改。我们已更新到 Gradle 3.5、Android SDK 26、Fresco 1.9.0 和 OkHttp 3.10.0，甚至 NDK API 目标到 API 16。这些更改应该不会出现问题，并会带来更快的构建速度。更重要的是，它将帮助开发人员遵守下个月生效的新的 Play 商店要求。

为此，我们要特别感谢Dulmandakh提交了许多 PR，使其成为可能👏。

在这方面还需要采取更多步骤，您可以在专门的问题（以及JSC 的一个副问题）中关注 Android 支持的未来规划和讨论。

新的 Node、Xcode、React 和 Flow – 哦天哪！​

Node 8 现在是 React Native 的标准。它实际上已经在测试中，但随着 Node 6 进入维护模式，我们全力以赴。React 也更新到了 16.4，这带来了大量的修复。

我们正在停止对 iOS 8 的支持，使 iOS 9 成为可支持的最旧 iOS 版本。我们预计这不会成为问题，因为任何可以运行 iOS 8 的设备都可以升级到 iOS 9。这一更改使我们能够删除为运行 iOS 8 的旧设备实现变通方法的很少使用的代码。

持续集成工具链已更新以使用 Xcode 9.4，确保所有 iOS 测试都在 Apple 提供的最新开发工具上运行。

我们已经升级到 Flow 0.75 以使用许多开发人员赞赏的新错误格式。我们还为更多组件创建了类型。如果您尚未在项目中强制执行静态类型，请考虑使用 Flow 在编码时而不是在运行时识别问题。

还有很多其他事情...​

例如，YellowBox 被替换为新的实现，这使得调试变得更好。

有关完整的发行说明，请参考此处的完整变更日志。并且请记住关注升级指南，以避免迁移到此新版本时出现问题。

最后一点：从本周开始，React Native 核心团队将恢复每月会议。我们将确保让每个人都了解所涵盖的内容，并确保在未来的会议中随时获取您的反馈。

祝大家编码愉快！

Lorenzo, Ryan, 以及整个 React Native 核心团队

**附注：**一如既往，我们想提醒大家，React Native 仍处于 0.x 版本，因为仍有许多更改正在进行中——因此请记住，在升级时，是的，可能仍然会崩溃或出现问题。请在问题和提交 PR 时相互帮助——并记住遵守执行的 CoC：屏幕的另一端总有人。

距离我们上次发布 React Native 的状态更新已经有一段时间了。

在 Facebook，我们比以往任何时候都更多地使用 React Native，并且用于许多重要项目。我们最受欢迎的产品之一是 Marketplace，它是我们应用程序中的顶级标签之一，每月有 8 亿人使用。自 2015 年创建以来，Marketplace 的所有部分都使用 React Native 构建，包括应用程序不同部分的 100 多个全屏视图。

我们也在应用程序的许多新部分使用 React Native。如果您上个月观看了 F8 主题演讲，您会认识献血、危机响应、隐私快捷方式和健康检查——所有这些都是最近使用 React Native 构建的功能。Facebook 主应用程序之外的项目也在使用 React Native。新的 Oculus Go VR 头显包含一个完全使用 React Native 构建的配套移动应用程序，更不用说 React VR 为头显本身中的许多体验提供支持。

当然，我们还使用许多其他技术来构建我们的应用程序。Litho 和 ComponentKit 是我们在应用程序中广泛使用的两个库；两者都提供了类似 React 的组件 API 来构建原生屏幕。React Native 的目标从来都不是取代所有其他技术——我们专注于使 React Native 本身变得更好，但我们很高兴看到其他团队借鉴 React Native 的思想，例如将即时热重载也引入非 JavaScript 代码。

架构​

我们在 2013 年启动 React Native 项目时，将其设计为在 JavaScript 和原生之间拥有一个单一的“桥接”，它是异步的、可序列化的和批处理的。就像 React DOM 将 React 状态更新转换为对 DOM API（如 document.createElement(attrs) 和 .appendChild()）的命令式、可变调用一样，React Native 被设计为返回一个列出要执行的突变（mutation）的单个 JSON 消息，例如 [["createView", attrs], ["manageChildren", ...]]。我们将整个系统设计为从不依赖于同步响应，并确保该列表中的所有内容都可以完全序列化为 JSON 并返回。我们这样做是因为它提供了灵活性：在此架构之上，我们能够构建诸如Chrome 调试工具之类的工具，这些工具通过 WebSocket 连接异步运行所有 JavaScript 代码。

在过去的 5 年里，我们发现这些最初的原则使得构建某些功能变得更加困难。异步桥接意味着您无法将 JavaScript 逻辑直接与许多期望同步响应的原生 API 集成。批处理桥接将原生调用排队，这意味着 React Native 应用程序更难调用原生实现的功能。可序列化桥接意味着不必要的复制，而不是直接在两个世界之间共享内存。对于完全用 React Native 构建的应用程序，这些限制通常是可以忍受的。但对于 React Native 与现有应用程序代码之间集成复杂的应用程序，它们令人沮丧。

我们正在对 React Native 进行大规模的重新架构，以使框架更具灵活性，并在混合 JavaScript/原生应用中更好地与原生基础设施集成。通过这个项目，我们将运用我们过去 5 年所学到的知识，逐步将我们的架构带入一个更现代的架构。我们正在重写 React Native 的许多内部组件，但大多数更改都在幕后：现有的 React Native 应用将继续运行，几乎或根本无需更改。

为了使 React Native 更轻量级并更好地融入现有的原生应用程序，这次重新架构有三个主要的内部变化。首先，我们正在改变线程模型。每个 UI 更新不再需要同时在三个不同的线程上执行工作，而是可以在任何线程上同步调用 JavaScript 进行高优先级更新，同时仍将低优先级工作放在主线程之外以保持响应能力。其次，我们正在将异步渲染功能集成到 React Native 中，以允许多个渲染优先级并简化异步数据处理。最后，我们正在简化我们的桥接，使其更快、更轻量；原生和 JavaScript 之间的直接调用更高效，并将使构建跨语言堆栈跟踪等调试工具变得更容易。

一旦这些更改完成，更紧密的集成将成为可能。今天，如果不通过复杂的 hack，就无法整合原生导航和手势处理，或像 UICollectionView 和 RecyclerView 这样的原生组件。在我们更改线程模型之后，构建这样的功能将变得简单明了。

我们将在今年晚些时候，待其接近完成时，发布更多关于这项工作的细节。

社区​

除了 Facebook 内部的社区，我们很高兴在 Facebook 之外拥有一个蓬勃发展的 React Native 用户和合作者群体。我们希望更多地支持 React Native 社区，既通过更好地服务 React Native 用户，又通过使项目更易于贡献。

就像我们的架构更改将帮助 React Native 与其他原生基础设施更清晰地互操作一样，React Native 在 JavaScript 端应该更精简，以更好地适应 JavaScript 生态系统，这包括使 VM 和打包器可互换。我们知道破坏性更改的步伐可能难以跟上，因此我们希望找到方法来减少主要发布。最后，我们知道有些团队正在寻求更全面的文档，例如启动优化方面，我们的专业知识尚未记录下来。预计在未来一年会看到其中一些变化。

如果您正在使用 React Native，您就是我们社区的一员；请继续告诉我们如何才能让 React Native 为您做得更好。

React Native只是移动开发人员工具箱中的一个工具，但我们坚信它——而且我们每天都在让它变得更好，去年有500多名贡献者提交了2500多次提交。

JavaScript！我们都喜欢它。但我们中的一些人也喜欢类型。幸运的是，存在为 JavaScript 添加更强类型的方法。我最喜欢的是TypeScript，但 React Native 原生支持Flow。您喜欢哪一个取决于个人偏好，它们都有各自的方法来为 JavaScript 添加类型的魔力。今天，我们将探讨如何在 React Native 应用程序中使用 TypeScript。

这篇文章以微软的TypeScript-React-Native-Starter仓库作为指南。

更新：自此博客文章撰写以来，事情变得更加容易。您可以通过运行一个命令来替换本文中描述的所有设置

npx react-native init MyAwesomeProject --template react-native-template-typescript

然而，Babel 对 TypeScript 的支持确实存在一些限制，上述博客文章对此进行了详细阐述。本篇文章中概述的步骤仍然有效，并且 Artsy 仍在生产环境中使用 react-native-typescript-transformer，但使用上述命令是开始使用 React Native 和 TypeScript 的最快方式。如果需要，您以后总是可以切换。

无论如何，玩得开心！原始博客文章继续如下。

先决条件​

由于您可能在多个不同的平台上开发，并且针对多种不同类型的设备，因此基本设置可能很复杂。您应该首先确保您可以在没有 TypeScript 的情况下运行一个纯 React Native 应用程序。按照 React Native 网站上的说明开始。当您成功部署到设备或模拟器后，您就可以开始一个 TypeScript React Native 应用程序了。

您还需要 Node.js、npm 和 Yarn。

初始化​

一旦您尝试搭建一个普通的React Native项目，您就可以开始添加TypeScript了。让我们继续进行。

react-native init MyAwesomeProject
cd MyAwesomeProject

添加TypeScript​

下一步是将 TypeScript 添加到您的项目中。以下命令将：

• 将 TypeScript 添加到您的项目
• 将 React Native TypeScript Transformer 添加到您的项目
• 初始化一个空的 TypeScript 配置文件，我们接下来会配置它
• 添加一个空的 React Native TypeScript Transformer 配置文件，我们接下来会配置它
• 添加 React 和 React Native 的类型定义

好的，让我们继续运行这些命令。

yarn add --dev typescript
yarn add --dev react-native-typescript-transformer
yarn tsc --init --pretty --jsx react
touch rn-cli.config.js
yarn add --dev @types/react @types/react-native

tsconfig.json 文件包含 TypeScript 编译器的所有设置。上面命令创建的默认设置大部分都很好，但请打开文件并取消注释以下行

{
  /* Search the config file for the following line and uncomment it. */
  // "allowSyntheticDefaultImports": true,  /* Allow default imports from modules with no default export. This does not affect code emit, just typechecking. */
}

rn-cli.config.js 包含 React Native TypeScript Transformer 的设置。打开它并添加以下内容

module.exports = {
  getTransformModulePath() {
    return require.resolve('react-native-typescript-transformer');
  },
  getSourceExts() {
    return ['ts', 'tsx'];
  },
};

迁移到 TypeScript​

将生成的 App.js 和 __tests_/App.js 文件重命名为 App.tsx。index.js 需要使用 .js 扩展名。所有新文件都应使用 .tsx 扩展名（如果文件不包含任何 JSX，则使用 .ts）。

如果你现在尝试运行这个应用程序，你会得到一个错误，比如 object prototype may only be an object or null。这是因为未能同时从 React 导入默认导出和命名导出。打开 App.tsx 并修改文件顶部的导入语句

-import React, { Component } from 'react';
+import React from 'react'
+import { Component } from 'react';

其中一些与 Babel 和 TypeScript 如何与 CommonJS 模块互操作的差异有关。将来，两者将在相同的行为上稳定下来。

此时，您应该能够运行React Native应用程序。

添加 TypeScript 测试基础结构​

React Native 附带 Jest，因此为了使用 TypeScript 测试 React Native 应用程序，我们希望将 ts-jest 添加到我们的 devDependencies 中。

yarn add --dev ts-jest

然后，我们将打开 package.json 并将 jest 字段替换为以下内容

{
  "jest": {
    "preset": "react-native",
    "moduleFileExtensions": [
      "ts",
      "tsx",
      "js"
    ],
    "transform": {
      "^.+\\.(js)$": "<rootDir>/node_modules/babel-jest",
      "\\.(ts|tsx)$": "<rootDir>/node_modules/ts-jest/preprocessor.js"
    },
    "testRegex": "(/__tests__/.*|\\.(test|spec))\\.(ts|tsx|js)$",
    "testPathIgnorePatterns": [
      "\\.snap$",
      "<rootDir>/node_modules/"
    ],
    "cacheDirectory": ".jest/cache"
  }
}

这将配置 Jest 以使用 `ts-jest` 运行 `.ts` 和 `.tsx` 文件。

安装依赖项类型声明​

为了在 TypeScript 中获得最佳体验，我们希望类型检查器能够理解我们依赖项的形状和 API。一些库将发布带有 .d.ts 文件（类型声明/类型定义文件）的包，这些文件可以描述底层 JavaScript 的形状。对于其他库，我们需要在 @types/ npm 作用域中显式安装相应的包。

例如，这里我们需要 Jest、React、React Native 和 React Test Renderer 的类型。

yarn add --dev @types/jest @types/react @types/react-native @types/react-test-renderer

我们将这些声明文件包保存到我们的**开发**依赖项中，因为这是一个 React Native **应用程序**，仅在开发期间使用这些依赖项，而不是在运行时使用。如果我们要将一个库发布到 NPM，我们可能需要将其中一些类型依赖项作为常规依赖项添加。

您可以在此处阅读更多关于获取.d.ts文件的信息。

忽略更多文件​

为了您的源代码控制，您将希望开始忽略 .jest 文件夹。如果您正在使用 git，我们可以直接将条目添加到我们的 .gitignore 文件中。

# Jest
#
.jest/

作为一个检查点，考虑将您的文件提交到版本控制。

git init
git add .gitignore # import to do this first, to ignore our files
git add .
git commit -am "Initial commit."

添加组件​

让我们为我们的应用程序添加一个组件。我们来创建一个 `Hello.tsx` 组件。这是一个教学组件，不是您在实际应用程序中会编写的东西，而是一些非平凡的例子，展示了如何在 React Native 中使用 TypeScript。

创建一个 components 目录并添加以下示例。

// components/Hello.tsx
import React from 'react';
import {Button, StyleSheet, Text, View} from 'react-native';

export interface Props {
  name: string;
  enthusiasmLevel?: number;
}

interface State {
  enthusiasmLevel: number;
}

export class Hello extends React.Component<Props, State> {
  constructor(props: Props) {
    super(props);

    if ((props.enthusiasmLevel || 0) <= 0) {
      throw new Error(
        'You could be a little more enthusiastic. :D',
      );
    }

    this.state = {
      enthusiasmLevel: props.enthusiasmLevel || 1,
    };
  }

  onIncrement = () =>
    this.setState({
      enthusiasmLevel: this.state.enthusiasmLevel + 1,
    });
  onDecrement = () =>
    this.setState({
      enthusiasmLevel: this.state.enthusiasmLevel - 1,
    });
  getExclamationMarks = (numChars: number) =>
    Array(numChars + 1).join('!');

  render() {
    return (
      <View style={styles.root}>
        <Text style={styles.greeting}>
          Hello{' '}
          {this.props.name +
            this.getExclamationMarks(this.state.enthusiasmLevel)}
        </Text>

        <View style={styles.buttons}>
          <View style={styles.button}>
            <Button
              title="-"
              onPress={this.onDecrement}
              accessibilityLabel="decrement"
              color="red"
            />
          </View>

          <View style={styles.button}>
            <Button
              title="+"
              onPress={this.onIncrement}
              accessibilityLabel="increment"
              color="blue"
            />
          </View>
        </View>
      </View>
    );
  }
}

// styles
const styles = StyleSheet.create({
  root: {
    alignItems: 'center',
    alignSelf: 'center',
  },
  buttons: {
    flexDirection: 'row',
    minHeight: 70,
    alignItems: 'stretch',
    alignSelf: 'center',
    borderWidth: 5,
  },
  button: {
    flex: 1,
    paddingVertical: 0,
  },
  greeting: {
    color: '#999',
    fontWeight: 'bold',
  },
});

哇！这很多，但让我们分解一下：

• 我们没有渲染像 `div`、`span`、`h1` 等 HTML 元素，而是渲染像 `View` 和 `Button` 这样的组件。这些是可以在不同平台上工作的原生组件。
• 样式是使用React Native提供的StyleSheet.create函数指定的。React的样式表允许我们使用Flexbox控制布局，并使用类似于CSS的其他结构来设置样式。

添加组件测试​

现在我们有了一个组件，让我们尝试测试它。

我们已经安装了 Jest 作为测试运行器。我们将为我们的组件编写快照测试，让我们添加快照测试所需的附加组件

yarn add --dev react-addons-test-utils

现在，让我们在 components 目录中创建一个 __tests__ 文件夹，并为 Hello.tsx 添加一个测试

// components/__tests__/Hello.tsx
import React from 'react';
import renderer from 'react-test-renderer';

import {Hello} from '../Hello';

it('renders correctly with defaults', () => {
  const button = renderer
    .create(<Hello name="World" enthusiasmLevel={1} />)
    .toJSON();
  expect(button).toMatchSnapshot();
});

首次运行测试时，它将创建渲染组件的快照并将其存储在 components/__tests__/__snapshots__/Hello.tsx.snap 文件中。当您修改组件时，您需要更新快照并检查更新以避免无意中的更改。您可以在此处阅读更多关于测试 React Native 组件的信息。

下一步​

查看官方React 教程和状态管理库Redux。这些资源在编写 React Native 应用程序时会很有帮助。此外，您可能需要查看ReactXP，这是一个完全用 TypeScript 编写的组件库，支持 Web 上的 React 和 React Native。

祝您在更类型安全的React Native开发环境中玩得开心！

Build.com，总部位于加利福尼亚州奇科，是最大的家居装修用品在线零售商之一。该团队在网络业务方面拥有 18 年的强大经验，并于 2015 年开始考虑开发移动应用程序。由于我们团队规模小且原生经验有限，因此开发独特的 Android 和 iOS 应用程序并不实际。相反，我们决定冒险尝试非常新的 React Native 框架。我们的首次提交是在 2015 年 8 月 12 日，当时使用的是 React Native v0.8.0！我们于 2016 年 10 月 15 日在两个应用商店上线。在过去的两年中，我们不断升级和扩展应用程序。我们目前使用的是 React Native 0.53.0 版本。

您可以在 https://www.build.com/app 上查看该应用。

功能​

我们的应用程序功能齐全，包含您对电子商务应用程序所期望的一切：产品列表、搜索和排序、配置复杂产品的功能、收藏夹等。我们接受标准信用卡支付方式以及 PayPal，对于 iOS 用户还支持 Apple Pay。

一些您可能没有想到的突出功能包括：

1. 大约 40 种产品提供 3D 模型，有 90 种饰面可供选择
2. 增强现实 (AR) 功能，让用户能够以 98% 的尺寸精度在家中看到灯具和水龙头的外观。Build.com React Native 应用在 Apple App Store 中被推荐用于 AR 购物！AR 现在可在 Android 和 iOS 上使用！
3. 协作项目管理功能，允许人们为项目不同阶段整理购物清单并协作选择

我们正在开发许多新的和令人兴奋的功能，这些功能将继续改善我们的应用体验，包括 AR 沉浸式购物的下一阶段。

我们的开发工作流程​

Build.com 允许每位开发人员选择最适合他们的工具。

• IDE 包括 Atom、IntelliJ、VS Code、Sublime、Eclipse 等。
• 对于单元测试，开发人员负责为任何新组件创建 Jest 单元测试，我们正在使用 jest-coverage-ratchet 增加应用程序旧部分的覆盖率。
• 我们使用 Jenkins 来构建我们的测试版和发布候选版本。这个过程对我们来说很有效，但仍然需要大量工作来创建发布说明和其他工件。
• 集成测试包括一个共享的测试人员池，他们在桌面、移动和网络上工作。我们的自动化工程师正在使用 Java 和 Appium 构建我们的自动化集成测试套件。
• 工作流程的其他部分包括详细的 eslint 配置、强制执行测试所需属性的自定义规则以及阻止违规更改的预提交钩子。

应用程序中使用的库​

Build.com 应用程序依赖于许多常见的开源库，包括：Redux、Moment、Numeral、Enzyme 和一堆 React Native 桥接模块。我们还使用许多分支的开源库；分支原因可能是它们被废弃了，或者我们需要自定义功能。粗略统计显示大约有 115 个 JavaScript 和原生依赖项。我们希望探索可以删除未使用库的工具。

我们正在通过 TypeScript 添加静态类型，并研究可选链。这些功能可以帮助我们解决我们仍然看到的一些错误类别

• 数据类型错误
• 由于对象不包含我们期望的内容，数据未定义

开源贡献​

由于我们高度依赖开源，我们的团队致力于回馈社区。Build.com 允许团队开源我们构建的库，并鼓励我们回馈我们使用的库。

我们发布并维护了许多 React Native 库

• react-native-polyfill
• react-native-simple-store
• react-native-contact-picker

我们还为许多库做出了贡献，包括：React 和 React Native，react-native-schemes-manager，react-native-swipeable，react-native-gallery，react-native-view-transformer，react-native-navigation。

我们的旅程​

在过去几年中，我们看到 React Native 及其生态系统取得了长足发展。早期，似乎每个 React Native 版本都会修复一些错误，但会引入更多错误。例如，远程 JS 调试在 Android 上中断了几个月。谢天谢地，2017 年情况变得稳定多了。

导航库​

我们反复面临的一个巨大挑战是导航库。很长一段时间以来，我们一直使用 Expo 的 ex-nav 库。它对我们来说运作良好，但最终被弃用了。然而，当时我们正处于大量功能开发中，因此没有时间更换导航库。这意味着我们不得不分叉该库并对其进行修补，以支持 React 16 和 iPhone X。最终，我们成功迁移到 react-native-navigation，希望它能继续得到支持。

桥接模块​

另一个巨大的挑战是桥接模块。当我们刚开始时，许多关键的桥接都缺失了。我的一个队友编写了 react-native-contact-picker，因为我们需要在我们的应用程序中访问 Android 联系人选择器。我们还看到许多桥接被 React Native 内部的变化所破坏。例如，React Native v40 中有一个破坏性变化，当我们升级应用程序时，我不得不提交 PR 来修复 3 或 4 个尚未更新的库。

展望未来​

随着 React Native 的持续发展，我们对社区的愿望清单包括

• 稳定并改进导航库
• 维护对 React Native 生态系统中库的支持
• 改善向项目添加原生库和桥接模块的体验

React Native 社区中的公司和个人在志愿投入时间和精力来改进我们都在使用的工具方面表现出色。如果您还没有参与开源，我希望您能尝试改进您使用的一些库的代码或文档。有很多文章可以帮助您入门，而且可能比您想象的要容易得多！