本周，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 支持并使用适用于 Windows 的 React Native，使人们能够利用他们的专业知识和代码库渲染到 Microsoft 的通用 Windows 平台。请关注下周的 Microsoft Build，了解他们对此的更多讨论。

关于开源的 React Radio 播客​

Eli 的演讲最后谈到了我们最近的开源工作。我们在3 月份更新了我们的进展，最近 Nader Dabit 和 Gant Laborde 邀请 Christoph 参加他们的播客 React Native Radio，聊聊 React Native 的开源情况。

播客亮点：​

• 我们讨论了 Facebook 的 React Native 团队如何看待开源，以及我们如何为 React Native 规模的项目构建一个可持续发展的社区。
• 作为 Lean Core 工作的一部分，我们正在按计划移除多个模块。WebView 和 React Native CLI 等许多模块在提取后收到了超过 100 个拉取请求。
• 接下来，我们将专注于彻底改造 React Native 网站和文档。敬请期待！

您很快就能在您喜欢的播客应用程序中找到该集，或者您可以在此处收听录音

欢迎使用 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 命令。

🤗 感谢​

许多新贡献者帮助从流类型生成原生代码和解决 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 几乎不使用的抽象。

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

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

主要用户问题​

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

投票最多的问题之一是升级到更高版本的 React Native 的开发人员体验。不幸的是，这不是我们自己经历的问题，因为我们从 master 运行 React Native。值得庆幸的是，社区成员已经开始着手解决这个问题

• 来自 Callstack 的Michał Pierzchała 通过在底层使用rn-diff-purge改进了 react-native 升级。我们还更新了网站，删除了过时的升级说明。
• 我们计划默认推荐 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 以及许多性能和功能改进。它目前已发布为候选版本，预计将在未来两周内稳定。

后续步骤​

在接下来的两个月里，我们将继续管理拉取请求，以保持进展，同时开始减少未解决的 GitHub 问题数量。我们将继续通过 Lean Core 项目减少 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 可以改进的地方，并协调围绕 Lean Core 项目 的努力——以及其他有趣的讨论。

@ReactNativeComm 🐣​

我们知道我们传达这些努力的方式并未如我们所愿般有效，为了让大家更容易跟上 React Native 社区中发生的一切（从发布到活跃讨论），我们创建了一个新的 Twitter 账户 @ReactNativeComm，您可以关注它。

如果您不在该社交网络上，请记住您始终可以通过 GitHub 监视仓库；此功能在过去几个月有所改进，现在可以只接收发布通知，所以无论如何您都应该考虑使用它。

未来展望 🎓​

在过去的 7-8 个月里，核心贡献者加强了 React Native 社区 GitHub 组织，以对 React Native 的开发拥有更多所有权，并加强与 Facebook 的协作。但这种方式始终缺乏类似项目可能具备的正式结构。

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

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

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

我希望您和我们一样对这个社区的未来感到兴奋。我们很高兴看到您参与到上述仓库中的讨论或您将创作的精彩代码中。

快乐编码！

今年，React Native 团队一直专注于大规模重构 React Native。正如 Sophie 在她的React Native 现状博文中提到的，我们已经制定了一个计划，以更好地支持 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 组件构建了一个使用 WKWebView 的新原生 iOS 后端。

这些更改的最后部分已在此提交中落地，并将随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，视口大小实际上会改变（如果内容内边距为正，则会变小）。

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 完全不支持无障碍提示。

问题三：忽略反色：​

一些视力受损的用户会在手机上使用反色以获得更高的屏幕对比度。Apple 为 iOS 提供了一个 API，允许开发人员忽略某些视图。这样，当用户开启反色设置时，图像和视频就不会失真。React Native 目前不支持此 API。

新 API 的设计​

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

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

背景

在 iOS 上，UIAccessibilityTraits 是一个可以设置在任何 NSObject 上的属性。通过 JavaScript 属性传递到原生代码的 17 个特性中的每一个都映射到 Objective-C 中的 UIAccessibilityTraits 元素。特性由长整型表示，所有设置的特性都通过按位或运算组合在一起。

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

所做的更改

对于我们的新属性，我们希望创建这两个属性的超集。我们决定主要以现有属性 accessibilityTraits 为蓝本设计新属性，因为 accessibilityTraits 的值明显更多。Android 对这些特性的功能将通过修改无障碍委托进行兼容。

iOS 上的 accessibilityTraits 可以设置为 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) 发布更加出色。

我们想通过感谢所有 67 位贡献者在总共 818 次提交（！）中付出的努力来结束本节，这些贡献将帮助您的应用程序变得更好 👏。

现在，话不多说...

重大更改​

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 Store 要求。

为此，我们要特别感谢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 核心团队

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

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

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

我们还将 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 被设计为返回一个单一的 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开发环境中玩得开心！