React Native 0.79 - 更快的工具和更多
·9 分钟阅读
今天我们很高兴发布 React Native 0.79！
此版本在多个方面进行了性能改进，并修复了多个错误。首先，由于延迟哈希，Metro 启动速度更快，并且稳定支持包导出。由于 JS bundle 压缩的更改以及更多内容，Android 中的启动时间也将得到改善。
React Native 0.78 - React 19 及更多
·10 分钟阅读
今天我们很高兴发布 React Native 0.78！
此版本在 React Native 中发布了 React 19 以及其他相关功能，例如对 Android Vector drawables 的原生支持以及对 iOS 更好的 brownfield 集成。
亮点
React Native 核心贡献者峰会 2024 回顾
·10 分钟阅读
每年，React Native 社区的核心贡献者都会与 React Native 团队聚在一起，共同塑造该项目的方向。
去年也不例外，只是略有不同。我们通常在 React Universe Conf（前身为 React Native EU）的前一天在弗罗茨瓦夫的 Callstack 总部会面。2024 年，吸取过去的经验，我们将峰会举办了连续两天，以便我们有更多非结构化的时间在一起。
这项年度传统已成为贡献者分享见解和表达担忧，以及核心团队分享其计划并收集 React Native 生态系统（包括合作伙伴公司、个人库作者和朋友）主要贡献者反馈的宝贵机会。
我们将峰会分为两个轨道，涵盖以下主题
- 发布
- 新架构之后会是什么？
- 原生模块的 Web API 规范
- LeanCore 2.0
- Nitro Modules - 通过将 props 暴露为 jsi::Values 来解锁视图组件
- 树外平台和 CocoaPods
- 桌面上的 React Native
在这篇博文中，我们想向您简要介绍一下这次聚会的成果。
发布
我们对 React Native 的发布流程进行了广泛的讨论。核心团队赞赏 Meta 外部的贡献者参与发布，并强调拥有每夜构建版本的重要性，这对于树外平台（如 React Native visionOS）、库维护者 (Reanimated) 和框架 (Expo) 尤其有益。我们讨论了发布的频率，有些人要求更频繁地发布以更快地发布修复程序，而另一些人则对第三方库的影响和升级工作表示担忧。
我们还集思广益，讨论如何减少意外的重大更改，并改进关于 React Native 和第三方依赖项之间兼容性的沟通。
本次会议表明，管理 React Native 的发布是多么复杂，以及考虑到需要考虑生态系统的所有不同部分，这个话题是多么微妙。
新架构之后会是什么？
既然新架构已经稳定发布，我们讨论了接下来应该关注什么。下一个重大事件可能是什么？主题围绕
- Web 兼容性 – 在关于 React Strict DOM 项目方向的讨论中得出结论，该项目应被视为临时 polyfill，而 Xplat 团队应将适当的跨平台功能实现到 React Native 的核心中。
- 稳定核心 API – 结果表明，我们需要就这对应用开发者、库作者、树外平台意味着什么达成更多共识。例如，可能需要从共享的 C++ 代码库中提取 iOS 和 Android 的平台原生逻辑。其中一部分已在 LeanCore 2.0 讨论中涵盖。
- 旧架构支持 – 正如预期的那样，团队确认基于并发渲染的新 React 19 功能在旧架构中不起作用。新功能主要针对新架构。由于 React 19 发布计划中的障碍，目前尚不清楚在哪里划定新旧架构都支持的功能之间的界限。
- React Native 的第三方库 – 如今，库作者可以使用 TurboModules、ExpoModules 以及最近的 NitroModules 来实现桥接原生平台功能的相同目标。我们需要关于如何做好这件事的更好文档。
- Brownfield 文档 – 在峰会召开时，将 React Native 集成到原生应用中的官方文档已经过时。从那时起，团队跟进了适用于 Android 和 iOS 的最新且更简单的文档。
- Metro web 的 Tree-shaking – 核心 Metro 团队对合并 Expo 团队在该领域的工作持开放态度。
原生模块的 Web API
本次会议专门讨论了 Microsoft 关于将 Web API 子集引入 React Native 的 RFC。它旨在通过利用熟悉的 API 来增强 React Native 的可扩展性并吸引更多 Web 开发者。开放访问大量现有的、没有显式 React Native 支持的开源 Web 库。
Web API 规范的标准化不仅有益，而且对于 React Native 的发展至关重要，并且与我们的多平台愿景和 react-strict-dom 项目非常吻合。Web 通过其规范提供统一的接口，而 React Native 社区模块目前缺乏这种接口。Microsoft 已经确定了大约 200 个重要的 Web API，这些 API 可以首先为他们支持的平台（iOS、Android、Windows 和 macOS）实现。
我们鼓励库开发者尽可能使其 API 与 Web 规范保持一致，因为这种标准化将提高跨平台的代码可移植性和开发者体验。
虽然该提案似乎对 React Native 的未来有益，但我们仍在集思广益，讨论后续步骤。我们注意到的一个担忧是 API 的治理，以及它们是否需要与平台实现分开存储在单独的存储库中。另一个担忧是，如果特定平台允许 W3C 未指定的行为，则可能偏离官方规范。我们需要弄清楚如何避免捆绑不必要的模块，例如使用 Babel 插件。更不用说这项倡议的范围非常大。
会议结论强化了两个关键点：首先，React Native 社区在尽可能采用 Web 兼容规范方面达成了高度一致。其次，我们需要为如何在不同平台上单独维护这些 Web API 实现建立清晰的技术策略。Microsoft 可以与 Callstack 合作改进原始 RFC，并为少量 API 生成概念验证实现作为社区倡议。这种渐进式方法将帮助我们在扩展范围之前验证设计和开发者体验。
LeanCore 2.0
2019 年，React Native 团队启动了 Lean Core 计划。目标是解决 React Native 核心的表面积，并减少过时和遗留的 API 和组件。从那时起，React Native 组件和 API 表面已经很久没有进行另一轮清理了。
如今，有许多组件没有得到积极维护，但有更好的社区替代方案。此外，还有一些组件具有重复项，最终应合并以提高可维护性。
在 API 方面，许多 JS 层 API 都与原生 iOS 和 Android 实现相关联，而不是真正与平台无关。例如，对于 Pressable，我们有 android_disableSound 和 android_ripple 等 props。理想情况下，React Native 组件应该具有尽可能小的 API 表面，并且不与任何特定平台相关联。
随着树外平台的增长并被生态系统更多地采用，需要有一条路径来减少 React Native 核心的组件和 API 表面，从而减轻 React Native 核心团队的负担，并使树外平台和库维护者更容易保持最新状态。
作为额外的奖励，这将使初级应用开发者更容易上手 React Native，因为他们需要学习的重复组件和“陷阱”更少。如果社区有更好的替代方案，可以向开发者指出并鼓励他们使用可用的社区替代方案。
在会议期间，我们讨论了
- Lean Core 的高层次动机以及对相关方（开发者、库维护者、Meta）的好处
- 一些真实世界生产 React Native 应用中正在使用的组件的聚合视图
- 从核心中移除候选组件的标准
- 执行 Lean Core 2.0 的明确行动计划，包括
- 弃用的高级流程
- 处理 Meta 内部正在使用具有更好社区替代方案的组件的情况，
作为下一步，核心贡献者小组将着手收集更多遥测数据和数据，评估社区替代方案，并汇总一份 RFC，详细说明拟议的更改。
Nitro Modules - 通过将 props 暴露为 jsi::Values 来解锁视图组件
最近，Marc Rousavy 引入了 Nitro Modules 作为创建原生模块的替代方法。Nitro Modules 利用实验性的 C++ Swift 互操作，并包含许多增强功能，可以在某些情况下提高性能。但是，在本次会议期间，我们讨论了 Nitro Modules 和现有 TurboModules 之间涉及的各种权衡。
虽然 Nitro Modules 提供了一些性能优势，但它们也存在局限性和需要解决的注意事项。例如，使用实验性互操作功能可能会引入 TurboModules 中不存在的复杂性或兼容性问题。我们的讨论重点是这些权衡以及将 Nitro Modules 的一些改进向上游迁移到 React Native Core 的可能性，这将使开发者能够从更高效的模块中受益。
树外平台和 CocoaPods
树外平台展示了 React Native 的全部功能，我们可以在移动设备、桌面设备甚至 VR/XR 设备上运行的不同平台之间共享一个 JS 代码库。目前，创建这样一个平台并非易事，实际上，没有关于如何创建、开发和维护的指南。此外，React Native Core 在某种程度上与 Android 和 iOS 平台相关联。未来，我们的目标是实现所有平台都被平等对待，并通过相同的 API 与 C++/JS 核心集成的场景。
在本次会议期间，不同平台的维护者讨论了问题是什么，他们遇到了哪些困难，以及统一创建和维护新树外平台的过程的解决方案应该是什么。
本次会议的另一个方面是讨论 CocoaPods 以及与管理原生依赖项相关的未来计划。最近，CocoaPods 团队宣布他们已转向维护模式，并且不会发布新的重大改进或功能。有多种替代方案可以使用，在本次会议期间，我们讨论了它们的优缺点，以及迁移会是什么样子。
桌面上的 React Native
来自 Microsoft 的 Steven 和 Saad，react-native-windows 和 react-native-macos 的维护者，主持了一次会议，听取和收集与桌面平台相关的贡献者的反馈。讨论的主题包括探索如何提高 React Native 在桌面平台上的采用率（例如在 Visual Studio 中拥有专用工作流程，或将桌面平台作为 Nx 的一部分公开），以及如何支持 Expo，这对于提高采用率来说是一个持续的痛点。
macOS 和 Windows 之间社区模块的可用性存在很大差异，这主要是因为 iOS 代码大多与 macOS 兼容，而 RNW 需要定制实现。在为 Windows 版 React Native 开发新架构时，该团队看到了 C++ 模块的潜力，它可以实现跨平台更广泛的代码共享，这有望减轻针对桌面平台的负担。值得注意的是，在社区方面，Software Mansion 正在努力为其最受欢迎的模块（如 React Native Screens、Gesture Handler 和 Reanimated）添加桌面支持。
我们仍然对几天时间一起度过几个小时所产生的知识共享和思想的交叉传播印象深刻。在本次峰会期间，我们为旨在帮助我们改进和重塑 React Native 生态系统的倡议播下了种子。
如果您有兴趣加入 React Native 的开发，请务必加入我们的开放倡议并阅读我们网站上的贡献指南。我们希望将来也能与您亲自见面！
React Native 0.77 - 新的样式功能、Android 的 16KB 页面支持、Swift 模板
·15 分钟阅读
今天我们很高兴发布 React Native 0.77！
此版本发布了多项功能：新的样式功能，例如支持 display: contents、boxSizing、mixBlendMode 和 outline 相关属性，以提供更强大的布局选项；Android 16KB 页面支持，以兼容更新的 Android 设备。我们还在通过将社区模板迁移到 Swift 来使其现代化，同时继续支持和维护与喜欢 Objective-C 的开发者的兼容性。
新架构已到来
·22 分钟阅读
默认启用新架构的 React Native 0.76 现已在 npm 上可用！
在 0.76 发布博客文章中，我们分享了此版本中包含的重大更改列表。在这篇文章中，我们将概述新架构以及它如何塑造 React Native 的未来。
新架构增加了对现代 React 功能的全面支持，包括 Suspense、Transitions、自动批处理 和 useLayoutEffect。新架构还包括新的 原生模块 和 原生组件 系统，使您可以编写类型安全的代码，并直接访问原生接口，而无需桥接。
此版本是我们自 2018 年以来一直在开发的 React Native 从头开始重写的结果，并且我们格外注意使新架构成为大多数应用的渐进式迁移。2021 年，我们创建了 新架构工作组，与社区合作，确保整个 React 生态系统的平滑升级体验。
大多数应用将能够以与任何其他版本相同的精力来采用 React Native 0.76。最流行的 React Native 库已经支持新架构。新架构还包括自动互操作层，以实现与面向旧架构的库的向后兼容性。
React Native 0.76 - 默认启用新架构、React Native DevTools 及更多
·10 分钟阅读
React Native 0.75 - 布局中支持百分比值、新架构稳定化、模板和 init 更新及更多
·14 分钟阅读
使用框架构建 React Native 应用
·4 分钟阅读
在 React Conf 上，我们更新了关于开始构建 React Native 应用的最佳工具的指南：一个 React Native 框架 - 一个包含构建生产就绪应用所需的所有 API 的工具箱。
现在，使用 React Native 框架（如 Expo）是创建新应用的推荐方法。
在这篇博文中，我们想详细介绍它们是什么，以及它们对您作为开始新项目的 React Native 开发者意味着什么。
React Native 0.74 - Yoga 3.0、无桥新架构及更多
·12 分钟阅读
React Native 0.73 - 调试改进、稳定的符号链接支持及更多
·10 分钟阅读
