跳到主要内容

52 篇带“announcement”标签的帖子

查看所有标签

React Native 团队原则

·阅读时长5分钟
Eli White
Eli White
Meta 软件工程师

Facebook 的 React Native 团队遵循一些原则,这些原则有助于确定我们如何优先处理 React Native 的工作。这些原则特指我们团队,不一定代表 React Native 社区中的所有利益相关者。我们在此分享这些原则,以便更透明地说明是什么驱动着我们,我们如何做出决策,以及我们如何集中精力。

原生体验

React Native 的首要任务是满足人们对每个平台的期望。这就是 React Native 渲染到平台原生组件的原因。我们重视原生外观和感觉,而不是跨平台一致性。

例如,React Native 中的 TextInput 在 iOS 上渲染为 UITextField。这确保了与密码管理器和键盘控件的集成能够开箱即用。通过使用平台原生组件,React Native 应用程序还能够与 Android 和 iOS 新版本的设计和行为变化保持同步。

为了与原生应用程序的外观和感觉保持一致,我们也必须匹配它们的性能。这是我们最雄心勃勃的努力重点。例如,Facebook 创建了 Hermes,一个为 Android 上的 React Native 从头开始构建的新 JavaScript 引擎。Hermes 显著改善了 React Native 应用程序的启动时间。我们还在进行重大的架构更改,以优化线程模型并使 React Native 更容易与原生代码互操作。

大规模

Facebook 应用中的数百个屏幕都是用 React Native 实现的。Facebook 应用被数十亿用户在各种设备上使用。这就是我们投入精力解决大规模最严峻问题的原因。

在我们的应用程序中部署 React Native 让我们能够发现小规模下看不到的问题。例如,Facebook 专注于改善从最新 iPhone 到许多旧代 Android 设备等广泛设备上的性能。这种关注促成了我们的架构项目,如 Hermes、Fabric 和 TurboModules。

我们已经证明 React Native 也可以扩展到大型组织。当数百名开发人员在同一个应用程序上工作时,渐进式采用是必须的。这就是为什么我们确保 React Native 可以一次采用一个屏幕。很快,我们将更进一步,实现将现有原生屏幕的单个原生视图迁移到 React Native。

对大规模的关注意味着我们团队目前没有在许多事情上工作。例如,我们团队不推动 React Native 在行业中的采用。我们也不积极为我们看不到大规模的问题构建解决方案。我们很自豪我们有许多合作伙伴和核心贡献者能够专注于社区的这些重要领域。

开发人员速度

出色的用户体验是迭代创建的。在运行中的应用中看到代码更改的结果应该只需要几秒钟。React Native 的架构使其能够在开发过程中提供近乎即时的反馈。

我们经常听到团队反馈,采用 React Native 显著提高了他们的开发速度。这些团队发现,开发过程中即时反馈使得尝试不同想法和添加额外细节变得更容易,因为他们不必为每一个小改动中断编码会话。

即时反馈并不是 React Native 提高开发人员速度的唯一方式。团队可以利用快速增长的高质量开源包生态系统。团队还可以在 Android、iOS 和 Web 之间共享业务逻辑。这有助于他们更快地发布更新并减少平台团队之间的组织孤岛。

每个平台

当我们在 2014 年推出 React Native 时,我们提出了我们的座右铭“一次学习,随处编写”——我们指的是随处开发人员应该能够接触到尽可能多的人,而不受设备型号或操作系统的限制。

React Native 针对非常不同的平台,包括移动、桌面、Web、电视、VR、游戏机等。我们希望在每个平台上实现丰富的体验,而不是要求开发人员为最低公分母构建。为了实现这一点,我们专注于支持每个平台的独特功能。这包括不同的输入机制(例如触摸、笔、鼠标)以及根本不同的消费体验,如 VR 中的 3D 环境。

这项原则指导了我们决定用跨平台 C++ 实现 React Native 的新核心架构,以促进跨平台的一致性。我们还在完善面向其他平台维护者(如 Microsoft 的 Windows 和 macOS)的公共接口。我们致力于使任何平台都能够支持 React Native。

声明式 UI

我们不相信在每个平台上部署完全相同的用户界面,我们相信用相同的声明式编程模型暴露每个平台的独特能力。我们的声明式编程模型是 React。

根据我们的经验,React 普及的单向数据流使应用程序更容易理解。我们更喜欢将屏幕表示为声明式组件的组合,而不是命令式管理的视图。React 在 Web 上的成功以及新的原生 Android 和 iOS 框架的方向表明,行业也已接受了声明式 UI。

React 普及了声明式用户界面。然而,仍然有许多未解决的问题,而 React 具有独特的优势来解决这些问题。React Native 将继续在 React 的创新基础上发展,并保持在声明式用户界面运动的最前沿。

发布 React Native 0.63,支持 LogBox

·阅读约8分钟
Mike Grabowski
Mike Grabowski
CTO 兼 Callstack 联合创始人

今天我们发布 React Native 0.63,默认开启 LogBox。

LogBox

我们从社区收到了频繁的反馈,指出 React Native 中的错误和警告难以调试。为了解决这些问题,我们审查了 React Native 中整个错误、警告和日志系统,并从头开始重新设计了它。

Screenshot of LogBox

LogBox 是 React Native 中经过完全重新设计的 redbox、yellowbox 和日志体验。在 0.62 中,我们将 LogBox 作为可选择的功能引入。在此版本中,我们将 LogBox 作为 React Native 中所有体验的默认设置。

LogBox 通过关注三个主要目标来解决错误和警告过于冗长、格式不佳或不可操作的抱怨:

  • 简洁:日志应提供调试问题所需的最小信息量。
  • 格式化:日志应格式化,以便您能快速找到所需信息。
  • 可操作:日志应可操作,以便您能修复问题并继续进行。

为实现这些目标,LogBox 包括:

  • 日志通知:我们重新设计了警告通知,并增加了对错误的支持,以便所有 console.warn 和 console.log 消息都显示为通知,而不是覆盖您的应用程序。
  • 代码帧:现在每个错误和警告都包含一个代码帧,在应用程序内直接显示日志的源代码,让您能够快速识别问题的来源。
  • 组件堆栈:所有组件堆栈现在都从错误消息中剥离出来,并放入单独的部分,其中显示前三个帧。这为您提供了一个单一、一致的空间来期望堆栈帧信息,而不会使日志消息混乱。
  • 堆栈帧折叠:默认情况下,我们现在折叠与您的应用程序代码无关的调用堆栈帧,这样您可以快速查看应用程序中的问题,而无需筛选 React Native 内部代码。
  • 语法错误格式化:我们改进了语法错误的格式,并添加了带语法高亮的代码帧,以便您可以看到错误的来源,修复它,并继续编码,而无需 React Native 阻碍您。

我们将所有这些功能封装到改进的视觉设计中,该设计在错误和警告之间保持一致,并允许在一个令人愉悦的 UI 中分页浏览所有日志。

通过此更改,我们还弃用 YellowBox,转而使用 LogBox API。

  • LogBox.ignoreLogs():此函数替代 YellowBox.ignoreLogs([]),用于静默任何与给定字符串或正则表达式匹配的日志。
  • LogBox.ignoreAllLogs():此函数替代 console.disableYellowBox,用于关闭错误或警告通知。注意:这仅禁用通知,未捕获的错误仍将打开全屏 LogBox。

在 0.63 版本中,使用这些已弃用模块或方法时将发出警告。请在它们在 0.64 版本中移除之前,更新您调用这些 API 的地方。

有关 LogBox 和调试 React Native 的更多信息,请参阅此处的文档。

Pressable

React Native 的构建旨在使应用程序能够满足用户对平台的期望。这包括避免“蛛丝马迹”——那些暴露出体验是用 React Native 构建的小细节。这些蛛丝马迹的一个主要来源是 Touchable 组件:ButtonTouchableWithoutFeedbackTouchableHighlightTouchableOpacityTouchableNativeFeedbackTouchableBounce。这些组件通过允许您向用户交互提供视觉反馈,使您的应用程序具有交互性。然而,由于它们包含内置样式和效果,与平台交互不匹配,用户可以判断哪些体验是用 React Native 编写的。

此外,随着 React Native 的发展和我们对高质量应用程序的要求提高,这些组件并没有随之发展。React Native 现在支持 Web、桌面和电视等平台,但对额外输入模式的支持一直不足。React Native 需要在所有平台上支持高质量的交互体验。

为了解决这些问题,我们正在发布一个名为 Pressable 的新核心组件。此组件可用于检测各种类型的交互。API 旨在提供对当前交互状态的直接访问,而无需在父组件中手动维护状态。它还旨在使平台能够扩展其功能,包括悬停、失焦、聚焦等。我们预计大多数人将构建和共享在底层利用 Pressable 的组件,而不是依赖像 TouchableOpacity 这样的默认体验。

import {Pressable, Text} from 'react-native';

<Pressable
onPress={() => {
console.log('pressed');
}}
style={({pressed}) => ({
backgroundColor: pressed ? 'lightskyblue' : 'white',
})}>
<Text style={styles.text}>Press Me!</Text>
</Pressable>;

Pressable 组件的简单示例

您可以从文档中了解更多信息。

原生颜色 (PlatformColor, DynamicColorIOS)

每个原生平台都有系统定义的颜色概念。这些颜色会自动响应系统主题设置,例如浅色或深色模式,辅助功能设置,例如高对比度模式,甚至其在应用程序中的上下文,例如包含视图或窗口的特性。

虽然可以通过 Appearance API 和/或 AccessibilityInfo 检测其中一些设置并相应地设置您的样式,但这种抽象不仅开发成本高昂,而且只是近似于原生颜色的外观。当在混合应用程序中工作时,这些不一致性尤其明显,其中 React Native 元素与原生元素并存。

React Native 现在提供了一个开箱即用的解决方案来使用这些系统颜色。PlatformColor() 是一个新 API,可以像 React Native 中的任何其他颜色一样使用。

例如,在 iOS 上,系统提供了一个名为 labelColor 的颜色。它可以在 React Native 中与 PlatformColor 一起使用,如下所示

import {Text, PlatformColor} from 'react-native';

<Text style={{color: PlatformColor('labelColor')}}>
This is a label
</Text>;

将 Text 组件的颜色设置为 iOS 定义的 labelColor。

另一方面,Android 提供了像 colorButtonNormal 这样的颜色。您可以在 React Native 中使用这种颜色:

import {View, Text, PlatformColor} from 'react-native';

<View
style={{
backgroundColor: PlatformColor('?attr/colorButtonNormal'),
}}>
<Text>This is colored like a button!</Text>
</View>;

将 View 组件的背景颜色设置为 Android 定义的 colorButtonNormal。

您可以从文档中了解有关 PlatformColor 的更多信息。您还可以查看 RNTester 中提供的实际代码示例

DynamicColorIOS 是一个仅限 iOS 的 API,可让您定义在浅色和深色模式下使用的颜色。与 PlatformColor 类似,它可以在任何可以使用颜色的地方使用。DynamicColorIOS 在底层使用 iOS 的 colorWithDynamicProvider

import {Text, DynamicColorIOS} from 'react-native';

const customDynamicTextColor = DynamicColorIOS({
dark: 'lightskyblue',
light: 'midnightblue',
});

<Text style={{color: customDynamicTextColor}}>
This color changes automatically based on the system theme!
</Text>;

根据系统主题更改文本颜色

您可以从文档中了解更多关于 DynamicColorIOS 的信息。

放弃对 iOS 9 和 Node.js 8 的支持

在发布四年多后,我们正在放弃对 iOS 9 的支持。这一更改将使我们能够更快地行动,通过减少需要放在原生代码中的兼容性检查的数量,以检测给定功能是否在特定 iOS 版本上受支持。凭借其 1% 的市场份额,它不应对您的客户产生太大负面影响。

同时,我们正在放弃对 Node 8 的支持。它的 LTS 维护周期于 2019 年 12 月到期。当前的 LTS 是 Node 10,它现在是我们正在针对的版本。如果您仍然使用 Node 8 进行 React Native 应用程序的开发,我们鼓励您升级以接收所有最新的安全修复和更新。

其他值得注意的改进

  • 支持在 <Text /> 中渲染 <View /> 而无需明确尺寸:您现在可以在任何 <Text /> 组件中渲染任何 <View />,而无需明确设置其宽度和高度,这以前并非总是可行。在以前的 React Native 版本中,这会导致 RedBox。
  • 将 iOS LaunchScreen 从 xib 更改为 storyboard:从 2020 年 4 月 30 日起,所有提交到 App Store 的应用程序都必须使用 Xcode storyboard 来提供应用程序的启动屏幕,并且所有 iPhone 应用程序都必须支持所有 iPhone 屏幕。此提交调整了默认的 React Native 模板以符合此要求。

致谢

感谢数百位贡献者,他们的努力使 0.63 版本成为可能!

注意

特别感谢 Rick Hanlon 撰写了关于 LogBox 的部分,以及 Eli White 撰写了本文的 Pressable 部分。

要查看所有更新,请参阅0.63 更新日志

发布 React Native 0.62,支持 Flipper

·阅读时长5分钟
Rick Hanlon
Facebook React Native 核心团队成员

今天我们发布了 React Native 0.62 版本,其中包括默认支持 Flipper。

此版本在全球大流行中发布。我们今天发布此版本是为了尊重数百位贡献者为实现此版本所做的工作,并防止发布落后于 master 太远。请注意贡献者帮助解决问题的能力有限,并在必要时准备延迟升级。

默认启用 Flipper

Flipper 是一个用于调试移动应用程序的开发工具。它在 Android 和 iOS 社区中很受欢迎,在此版本中,我们已默认启用对新的和现有 React Native 应用程序的支持。

Screenshot of Flipper for React Native

Flipper 提供以下开箱即用的功能:

  • Metro 操作:直接从工具栏重新加载应用并触发开发者菜单。
  • 崩溃报告器:查看 Android 和 iOS 设备的崩溃报告。
  • React DevTools:将最新版本的 React DevTools 与所有其他工具一起使用。
  • 网络检查器:查看设备应用程序发出的所有网络请求。
  • Metro 和设备日志:查看、搜索和筛选来自 Metro 和设备的所有日志。
  • 原生布局检查器:查看和编辑 React Native 渲染器输出的原生布局。
  • 数据库和偏好设置检查器:查看和编辑设备数据库和偏好设置。

此外,由于 Flipper 是一个可扩展的平台,它提供了一个从 NPM 拉取插件的市场,因此您可以发布和安装特定于您的工作流程的自定义插件。在此处查看可用插件:此处

有关更多信息,请查看 Flipper 文档

新的暗模式功能

我们添加了一个新的 Appearance 模块,用于访问用户的外观偏好设置,例如他们首选的配色方案(浅色或深色)。

const colorScheme = Appearance.getColorScheme();
if (colorScheme === 'dark') {
// Use dark color scheme
}

我们还添加了一个 Hook 以订阅用户偏好设置的状态更新。

import {Text, useColorScheme} from 'react-native';

const MyComponent = () => {
const colorScheme = useColorScheme();
return <Text>useColorScheme(): {colorScheme}</Text>;
};

有关更多信息,请参阅 AppearanceuseColorScheme 的文档。

将 Apple TV 迁移到 react-native-tvos

作为我们精简核心工作的一部分,并使 Apple TV 与 React Native Windows 和 React Native macOS 等其他平台保持一致,我们已开始从核心代码中移除 Apple TV 相关的特定代码。

今后,React Native 的 Apple TV 支持将由 react-native-community/react-native-tvos 及其相应的 react-native-tvos NPM 包维护。这是主仓库的完整分支,仅包含支持 Apple TV 所需的更改。

react-native-tvos 的发布将基于 React Native 的公开版本。对于 react-native 的 0.62 版本,请将 Apple TV 项目升级到使用 react-native-tvos 0.62。

更多升级支持

当 0.61 发布时,社区推出了一款新的升级助手工具,以支持开发人员升级到新版本的 React Native。升级助手提供了您当前版本到目标版本之间的更改差异,让您可以看到特定升级所需进行的更改。

即使有这个工具,升级时也会出现问题。今天,我们通过宣布 Upgrade-Support 来提供更专业的升级支持。Upgrade Support 是一个 GitHub 问题跟踪器,用户可以在其中提交针对其项目升级的特定问题,以获得社区的帮助。

我们一直在努力改进升级体验,希望这些工具能为用户提供在尚未涵盖的边缘情况中所需的帮助。

其他改进

  • LogBox:我们正在添加新的 LogBox 错误和警告体验作为可选功能;要启用它,请在您的 index.js 文件中添加 require('react-native').unstable_enableLogBox()
  • React DevTools v4:此更改包括升级到最新的 React DevTools,它提供了显著的性能提升、改进的导航体验以及对 React Hooks 的完全支持。
  • 辅助功能改进:我们对辅助功能进行了改进,包括添加了accessibilityValueTouchables 上缺失的 props,onSlidingComplete 辅助功能事件,以及将 Switch 组件的默认角色从 "button" 更改为 "switch"

重大变更

  • 移除 PropTypes:我们正在从核心组件中移除 propTypes,以减少 React Native 核心对应用大小的影响,并倾向于在编译时而非运行时检查的静态类型系统。
  • 移除 accessibilityStates:我们移除了已弃用的 accessibilityStates 属性,取而代之的是新的 accessibilityState prop,这是一种更具语义性的方式,让组件向辅助功能服务描述其状态信息。
  • TextInput 更改:我们从 TextInput 中移除了 onTextInput,因为它不常见,不符合 W3C 标准,并且在 Fabric 中难以实现。我们还移除了未文档化的 inputView prop 和 selectionState

弃用

  • AccessibilityInfo.fetch 已被弃用,但在此版本中我们添加了一个警告
  • 现在要求设置 useNativeDriver,以支持将来切换默认值。
  • Animated 组件的 ref 现在是内部组件,并弃用getNode

致谢

感谢数百位贡献者,他们的努力使 0.62 版本成为可能!

要查看所有更新,请参阅 0.62 更改日志

认识 Doctor,一个新的 React Native 命令

·阅读时长2分钟
Lucas Bento
React Native 社区

经过 React Native 社区 6 位贡献者提交的 20 多个拉取请求,我们很高兴推出 react-native doctor,这是一个新命令,旨在帮助您入门、排除故障并自动修复开发环境中的错误。doctor 命令深受 ExpoHomebrew 自己的 doctor 命令的启发,并融入了 Jest 的 UI 灵感。

发布 React Native 0.61,支持 Fast Refresh

·3 分钟阅读
Dan Abramov
Facebook React 核心团队

我们很高兴地宣布 React Native 0.61 发布,其中包含我们称之为 Fast Refresh 的全新重载体验。

快速刷新

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

在 React Native 0.61 中,**我们将现有的“实时重载”(保存时重载)和“热重载”功能统一为一个名为“Fast Refresh”的全新功能**。Fast Refresh 从头开始实现,遵循以下原则:

  • Fast Refresh **完全支持现代 React**,包括函数组件和 Hooks。
  • Fast Refresh **在出现拼写错误和其他错误后能优雅地恢复**,并在需要时回退到完全重载。
  • Fast Refresh **不执行侵入性代码转换**,因此它足够可靠,可以默认开启。

要查看 Fast Refresh 的实际效果,请观看此视频:

试试看,并告诉我们你的想法!如果你愿意,可以在开发菜单(iOS 上按 Cmd+D,Android 上按 Cmd+M 或 Ctrl+M)中将其关闭。开启和关闭是即时的,因此你可以随时进行操作。

以下是一些 Fast Refresh 的提示:

  • Fast Refresh 默认保留函数组件(和 Hooks!)中的 React 本地状态。
  • 如果你需要在每次编辑时重置 React 状态,你可以在包含该组件的文件中添加特殊的 // @refresh reset 注释。
  • Fast Refresh 始终重新挂载类组件而不保留状态。这确保了其可靠性。
  • 我们都会在代码中犯错!Fast Refresh 在你保存文件后会自动重试渲染。你无需在修复语法或运行时错误后手动重新加载应用程序。
  • 在编辑过程中添加 console.logdebugger 语句是一种很棒的调试技巧。

请在 GitHub 上报告 Fast Refresh 的任何问题,我们会进行调查。

其他改进

  • 修复了 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 变更日志

认识 Hermes,一个为 React Native 优化的新 JavaScript 引擎

·阅读时长2分钟
Rachel Nabors
Facebook 文档工程师

上周在 Chain React 大会上,我们宣布推出 Hermes,这是我们 Facebook 内部一直在开发的一款开源 JavaScript 引擎。它是一款小型轻量级 JavaScript 引擎,经过优化,可在 Android 上运行 React Native。快来了解一下吧!

Hermes 通过减少内存使用、缩小下载大小以及缩短应用程序可用时间或“交互时间 (TTI)”来提高 React Native 性能。

“在分析性能数据时,我们注意到 JavaScript 引擎本身是启动性能和下载大小的一个重要因素。有了这些数据,我们知道我们必须针对移动电话(相比台式机或笔记本电脑)更为受限的环境优化 JavaScript 性能。在探索了其他选项之后,我们构建了一个名为 Hermes 的全新 JavaScript 引擎。它旨在提高应用程序性能,重点关注我们的 React Native 应用程序,即使是在内存有限、存储缓慢和计算能力降低的大众市场设备上。”——Hermes:一款从 React Native 开始,为移动应用程序优化的开源 JavaScript 引擎

想立即开始吗?务必查看我们的新指南,了解如何在现有 React Native 应用程序中启用 Hermes

Hermes 和 React Native 徽标结合成一只带翼的愤怒之鸟,从一部发光的、可能是 Android 手机中在雷电风暴中升起。 插图作者:Rachel Nabors

发布 React Native 0.60

·6 分钟阅读
Ryan Turner
核心维护者与 React Native 开发者

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

关注可访问性

可访问性 API 方面已有多项改进,例如 announceForAccessibility,以及 rolesaction supportflags 等的改进。可访问性是一门复杂的科学,但我们希望这些改进能让 A11Y 变得更容易一些。请务必查看 React Native 2019 年 6 月开源更新,了解这些更改的更多详细信息。

重新开始

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

The new init screen helps developers get started from the get-go with resources and a good example

AndroidX 支持

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

通过此更改,React Native 应用程序将需要开始使用 AndroidX。它们不能在同一个应用程序中并排使用,因此所有应用程序代码和依赖项代码都需要使用其中一个。

matt-oakesdiscussions-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! 存在兼容性问题,我们正在跟踪一个问题,其中包含解决方案和未来的补丁。

精简核心移除

WebViewNetInfo 之前已被提取到单独的存储库中,在 0.60 中,我们已经完成了将它们从 React Native 存储库中迁移出去的工作。此外,为了回应社区对新 App Store 政策的反馈,Geolocation 也已被提取。如果你还没有这样做,请通过添加对 react-native-webview@react-native-community/netinfo@react-native-community/geolocation 的依赖来完成迁移。如果你想要一个自动化解决方案,可以考虑使用 rn-upgrade-deprecated-modules。自提取以来,维护者已向这些存储库提交了 100 多个提交,我们很高兴看到社区的支持!

原生模块现在已自动链接

开发 React Native CLI 的团队对原生模块链接引入了重大改进,称为自动链接!大多数情况下不再需要使用 react-native link。同时,团队全面改进了链接过程。请务必按照上述文档中所述,react-native unlink 任何现有的依赖项。

升级助手

@lucasbento@pvinis@kelset@watadarkstar 构建了一个名为 升级助手 的出色工具,以简化升级过程。它帮助使用 brownfield 应用程序或复杂自定义的 React Native 用户查看版本之间发生了哪些变化。查看更新的升级文档,并立即尝试升级!

Upgrade Helper cleanly and easily shows the changes needed to migrate to a different version of React Native

致库维护者的一封信

AndroidX 的更改几乎肯定需要更新您的库,因此请务必尽快包含支持。如果您暂时无法升级,请考虑使用 jetifier 检查您的库,以确认用户能够在构建时修补您的库。

查看自动链接文档以更新您的配置和自述文件。根据您的库以前的集成方式,您可能还需要进行一些额外的更改。有关如何定义依赖项接口的信息,请查看 CLI 的依赖项指南。

致谢

虽然这些是我们注意到的亮点,但还有许多其他令人兴奋的更新。要查看所有更新,请查看更新日志。一如既往,请继续关注更多新闻。同时,请尽情享受 0.60 版本!

2019 年 6 月 React Native 开源更新

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

代码与社区健康

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

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

有意义的社区贡献

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

精简核心

精简核心 的主要动机是将模块从 React Native 中拆分到单独的存储库中,以便它们能够得到更好的维护。在短短六个月内,像 WebViewNetInfoAsyncStorage网站CLI 等存储库总共收到了 800 多个 Pull Request。除了更好的维护之外,这些项目还可以比 React Native 本身更频繁地独立发布。

我们还借此机会从 React Native 本身中删除了过时的 polyfill 和遗留组件。过去为了支持旧版 JavaScriptCore (JSC) 中的 `Map``Set` 等语言特性,polyfill 是必要的。现在 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 中。

不幸的是,我们尚未能改进所有方面。

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

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

持续集成

Facebook 首先将所有 Pull Request 和内部更改直接合并到 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,它即将发布。这将是令人兴奋的

F8 和开源播客中的 React Native

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

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

Facebook 开发者网站上查看视频

F8 Talk about React Native

演讲亮点:

  • 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 DabitGant 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

·7分钟阅读
Ryan Turner
核心维护者与 React Native 开发者

欢迎使用 React Native 0.59 版本!这是一个重要的版本,由 88 位贡献者提交了 644 次提交。贡献也以其他形式出现,因此感谢您维护问题、培养社区并向人们介绍 React Native。本月带来了一些备受期待的更改,我们希望您会喜欢它们。

🎣 Hooks 来了

React Hooks 是此版本的一部分,它允许您在组件之间重用有状态逻辑。关于 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 识别需要延迟加载的组件。具有深层和多样化组件架构的应用程序将看到最大的改进。

source of the metro.config.js file in the 0.59 template, demonstrating where to enable inlineRequires

在默认启用此功能之前,我们需要社区告知我们它的工作原理。当您升级到 0.59 时,将会有一个新的 metro.config.js 文件;将选项设置为 true 并向我们提供您的反馈!阅读性能文档中有关内联 require 的更多信息,以对您的应用程序进行基准测试。

🚅 精简核心正在进行中

React Native 是一个庞大而复杂的项目,拥有复杂的仓库。这使得代码库对贡献者而言不那么容易上手,难以测试,并且作为开发依赖项显得臃肿。精简核心是我们通过将代码迁移到单独的库以更好地管理来解决这些问题的努力。过去的几个版本已经迈出了第一步,但让我们认真对待

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

在接下来的几个月里,将有更多组件遵循这条路径走向更精简的核心。我们正在为此寻求帮助 — 请前往精简核心伞形项目贡献一份力量。

👩🏽‍💻 CLI 改进

React Native 的命令行工具是开发人员进入生态系统的入口点,但它们存在长期存在的问题,并且缺乏官方支持。CLI 工具已移至新仓库,并且一组专门的维护者已经取得了一些令人兴奋的改进。

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

0.58&#39;s CLI is slow to start0.58&#39;s CLI is nearly instantaneous

🚀 升级到 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 核心团队