跳过主内容

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
微软高级产品经理

每年，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 来实现桥接原生平台功能的相同目标。我们需要更好的文档来指导如何做好这一点。
  • Brownfield 文档——在峰会召开时，将 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 表面，且不与任何特定平台绑定。

随着树外平台（Out-of-Tree platforms）的增长并被生态系统更广泛地采用，需要有途径来减少 React Native 核心的组件和 API 表面积，从而减轻 React Native 核心团队的负担，并显著简化树外平台和库维护者的更新工作。

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

会议期间，我们讨论了

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

下一步，一群核心贡献者将着手收集更多的遥测数据和信息，评估社区替代方案，并起草一份 RFC，详细说明提议的变更。

Nitro 模块 - 通过将 prop 暴露为 jsi::Values 解除视图组件的限制​

最近，Marc Rousavy 引入了 Nitro 模块作为创建原生模块的替代方法。Nitro 模块利用实验性的 C++ Swift 互操作性，并包含一系列改进，可在某些场景下提升性能。然而，在本次会议中，我们讨论了 Nitro 模块与现有 TurboModules 之间涉及的各种权衡。

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

树外平台与 CocoaPods​

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

我们仍然惊叹于几天内共度数小时，竟然带来了如此多的知识共享和思想碰撞。在这次峰会上，我们为将帮助我们改进和重塑 React Native 生态系统的各项倡议播下了种子。

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