跳到主要内容

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 – 结果表明，我们需要就这对应用开发者、库作者、树外平台意味着什么达成更多共识。例如，可能有必要从共享的 C++ 代码库中提取 iOS 和 Android 的平台原生逻辑。其中一部分已在 LeanCore 2.0 讨论中涵盖。
  • 旧架构支持 – 正如预期的那样，团队确认基于并发渲染的新 React 19 功能在旧架构中无法工作。新功能主要针对新架构。由于 React 19 发布计划中的障碍，目前仍不清楚如何在新旧架构都支持的功能之间划清界限。
  • React Native 的第三方库 – 今天，我们库作者可以使用 TurboModules、ExpoModules，最近还可以使用 NitroModules 来实现相同的目标，即桥接原生平台功能。我们需要更好的文档来说明如何做好这一点。
  • 棕地文档 – 在峰会召开时，将 React Native 集成到原生应用中的官方文档已经过时。从那时起，团队一直在跟进，为 Android 和 iOS 提供了最新的、更简单的文档。
  • Metro web 的 Tree-shaking – 核心 Metro 团队愿意合并 Expo 团队在该领域的工作成果。

原生模块的 Web API​

本次会议专门讨论了微软的 RFC，该 RFC 围绕着将 Web API 子集引入 React Native 的想法。它旨在通过利用熟悉的 API 来增强 React Native 的可扩展性并吸引更多 Web 开发人员。开放访问大量现有的、没有明确 React Native 支持的开源 Web 库。

web-apis

Web API 规范的标准化不仅有益，而且对于 React Native 的发展至关重要，并且与我们的多平台愿景和 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 这样的 props。理想情况下，React Native 组件应该具有尽可能小的 API 表面，且不与任何特定平台绑定。

随着树外平台的增长并被生态系统更多地采用，需要找到一种方法来减少 React Native 核心的组件和 API 表面，从而减轻 React Native 核心团队的负担，并使树外平台和库维护者更容易保持更新。

作为额外的奖励，这将使初级应用开发人员更容易上手 React Native，因为他们需要学习的重复组件和“陷阱”更少。在有更好的社区替代方案的情况下，可以引导和鼓励开发人员使用可用的社区替代方案。

在会议期间，我们讨论了

  • Lean Core 的高层动机以及对相关方（开发者、库维护者、Meta）的好处
  • 对一些真实世界的生产 React Native 应用中正在使用的组件的汇总视图
  • 从核心中移除的候选组件的标准
  • 执行 Lean Core 2.0 的明确行动计划，包括
    • 弃用的高层流程
    • 处理 Meta 内部正在使用的组件，但有更好的社区替代方案的情况

作为下一步，一组核心贡献者将着眼于收集更多遥测和数据，评估社区替代方案，并整理一份 RFC 详细说明拟议的更改。

Nitro 模块 - 通过将 props 暴露为 jsi::Values 来解除视图组件的阻塞​

最近，Marc Rousavy 引入了 Nitro 模块，作为创建原生模块的替代方法。Nitro 模块利用实验性的 C++ Swift Interop 并包含许多增强功能，这些功能可以在某些情况下提高性能。然而，在本次会议期间，我们讨论了 Nitro 模块和现有 TurboModules 之间涉及的各种权衡。

虽然 Nitro 模块提供了一些性能优势，但它们也存在需要解决的局限性和考虑因素。例如，使用实验性的互操作功能可能会引入 TurboModules 中不存在的复杂性或兼容性问题。我们的讨论重点是这些权衡以及将 Nitro 模块的一些改进向上游合并到 React Native Core 中的潜力，这可以让开发人员从更高效的模块中受益。

树外平台 & CocoaPods​

树外平台展示了 React Native 的全部功能，我们可以在运行在我们移动设备、桌面甚至 VR/XR 设备上的不同平台之间共享一个 JS 代码库。目前创建这样一个平台并不是最容易的过程，实际上没有关于如何创建、开发和维护的指南。此外，React Native Core 在某种程度上与 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 需要定制的实现。在为 Windows 版 React Native 开发新架构时，团队看到了 C++ 模块的潜力，它可以实现更多跨平台的代码共享，这有望减轻针对桌面平台的负担。值得注意的是，在社区方面，Software Mansion 正在努力为其最受欢迎的模块（如 React Native Screens、Gesture Handler 和 Reanimated）添加桌面支持。

我们仍然对几天在一起花费几个小时就能产生如此多的知识共享和思想交流印象深刻。在本次峰会期间，我们为旨在帮助我们改进和重塑 React Native 生态系统的倡议播下了种子。

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