跳到主要内容

React Native 核心贡献者峰会 2024 回顾

·10 分钟阅读
Michał Pierzchała
Michał Pierzchała
技术主管 @ Callstack
Szymon Rybczak
Szymon Rybczak
Callstack 软件工程师
Mo Javad
Mo Javad
移动主管（英国）@ Theodo
Steven Moyes
Steven Moyes
高级产品经理 @ Microsoft

每年，React Native 社区的核心贡献者都会与 React Native 团队齐聚一堂，共同塑造这个项目的发展方向。

去年也一样——只有一个小例外。我们通常会在 React Universe Conf（前 React Native EU）前一天，在弗罗茨瓦夫的 Callstack 总部举行会议。2024 年，我们吸取了过去的经验，连续两天举办了峰会，以便有更多非结构化的时间在一起。

all-participants

这项年度传统已成为贡献者分享见解和表达顾虑的宝贵机会，也是核心团队分享计划并收集 React Native 生态系统中关键贡献者（包括合作公司、独立库作者和朋友）反馈的平台。

我们将峰会分为两个主题，涵盖以下议题：

在这篇博文中，我们想让您一窥本次会议成果的概览。

发布​

我们对 React Native 的发布流程进行了广泛的讨论。核心团队高度重视来自 Meta 之外的贡献者参与发布，并强调了夜间发布的重要性，这对 React Native visionOS 等树外平台、库维护者（Reanimated）和框架（Expo）尤其有益。我们讨论了发布的频率，一些人要求更频繁地发布以更快地交付修复，而另一些人则对第三方库和升级工作的影响表示担忧。

我们还集思广益，探讨了减少意外的破坏性变更以及改善 React Native 与第三方依赖项之间兼容性沟通的方法。

本次会议表明，管理 React Native 的发布非常复杂，而且鉴于生态系统中需要考虑的各种不同部分，这个话题非常微妙。

新架构之后是什么？​

既然新架构已经稳定发布，我们讨论了下一步应该关注什么。下一个重大的事情可能是什么？话题围绕以下内容展开：

  • Web 兼容性 - 在对 React Strict DOM 项目的方向进行讨论后得出结论，该项目应被视为临时 polyfill，同时 Xplat 团队将在 React Native 的核心中实现真正的跨平台功能。
  • 稳定核心 API - 结果表明，我们需要就这对于应用程序开发者、库作者、树外平台意味着什么达成更多共识。例如，可能需要将 iOS 和 Android 的平台原生逻辑从共享的 C++ 代码库中提取出来。其中一部分内容已包含在 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​

本次会议专门讨论了微软的一项 RFC，其核心思想是将一部分 Web API 引入 React Native。它旨在通过利用熟悉的 API 来增强 React Native 的可扩展性并吸引更多 Web 开发者。开放对大量现有的、没有明确 React Native 支持的开源 Web 库的访问。

web-apis

标准化 Web API 规范不仅有利于 React Native 的发展，而且至关重要，并且与我们的 Many Platforms 愿景和 react-strict-dom 项目非常契合。Web 通过其规范提供了一个统一的接口，而 React Native 社区模块目前缺乏这一点。微软已确定了约 200 个重要的 Web API，可以首先在它们支持的平台：iOS、Android、Windows 和 macOS 上实现。

我们鼓励库开发者尽可能使他们的 API 与 Web 规范保持一致，因为这种标准化将提高跨平台的代码可移植性和开发者体验。

虽然该提案对 React Native 的未来似乎很有益，但我们仍在集思广益讨论下一步。我们注意到的一点是 API 的治理问题，以及它们是否需要与平台实现分开存放于一个单独的仓库中。另一个问题是，如果某个特定平台允许出现 W3C 规范中未指定的行为，如何避免与其官方规范发生分歧。我们需要弄清楚如何避免打包不必要的模块，例如使用 Babel 插件。更不用说这项举措的范围相当庞大。

会议的结论强化了两个关键点：第一，React Native 社区在尽可能采用 Web 兼容规范方面有很强的共识。第二，我们需要制定一个清晰的技术战略，说明如何为不同平台分别维护这些 Web API 的实现。微软与 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 等属性。理想情况下，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 Interop，并包含许多可以在某些场景下提高性能的增强功能。然而，在本次会议中，我们讨论了 Nitro Modules 与现有 TurboModules 之间的各种权衡。

虽然 Nitro Modules 提供了某些性能优势，但它们也存在需要解决的局限性和考虑因素。例如，使用实验性互操作功能可能会引入 TurboModules 不存在 的复杂性或兼容性问题。我们的讨论集中在这些权衡以及将 Nitro Modules 的某些改进上游化到 React Native Core 的潜力上，这将使开发者能够为所有人带来更高效的模块。

树外平台 & CocoaPods​

树外平台展示了 React Native 的全部威力，我们可以将一个 JS 代码库在我们的移动设备、桌面或 VR/XR 设备上运行的不同平台之间共享。创建这样一个平台目前并非最简单的过程，实际上，关于如何创建、开发和维护这些平台没有明确的指导方针。此外，React Native 核心在某种程度上与 Android 和 iOS 平台绑定。未来，我们可以朝着所有平台享有同等待遇，并通过相同的 API 与 C++/JS 核心集成的情景努力。

oot-platforms

在本次会议期间，不同平台的维护者讨论了存在的问题、他们面临的困难以及应该如何统一创建和维护新的树外平台的流程。

本次会议的另一个方面是讨论 CocoaPods 和未来与原生依赖项管理相关的计划。最近，CocoaPods 团队宣布他们已进入维护模式，不会发布新的重大改进或功能。存在各种可以使用的替代方案，在本次会议中我们讨论了它们的优缺点以及迁移会是什么样子。

React Native 桌面版​

来自微软的 Steven 和 Saad，他们是 react-native-windows 和 react-native-macos 的维护者，主持了一次会议，听取并收集了与桌面平台相关的贡献者的反馈。讨论的主题包括探讨如何增加 React Native 在桌面端的采用（例如，在 Visual Studio 中拥有专门的工作流，或将桌面版作为 Nx 的一部分公开），以及如何支持 Expo，这是一个持续阻碍采用的痛点。

macOS 和 Windows 之间的社区模块可用性存在很大差异，这主要是由于 iOS 代码与 macOS 大部分兼容，而 RNW 需要定制实现。在为 React Native for Windows 进行新架构开发的过程中，该团队看到了 C++ 模块在跨平台代码共享方面的潜力，这有望减轻针对桌面平台的负担。值得注意的是，在社区方面，Software Mansion 正在努力为其最受欢迎的模块（如 React Native Screens、Gesture Handler 和 Reanimated）添加桌面支持。

我们仍然对在短短几天内投入数小时共同工作所产生的知识共享和想法的交叉融合感到印象深刻。在本次峰会期间，我们为有助于改进和重塑 React Native 生态系统的举措播下了种子。

如果您有兴趣加入 React Native 的开发，请务必加入我们的开放倡议，并阅读我们网站上的 贡献指南。我们希望将来也能与您在线下见面！