跳到主要内容

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 项目的方向，它应该被视为一个临时填充，而 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​

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

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 等 prop。理想情况下，React Native 组件应具有尽可能小的 API 表面，且不与任何特定平台绑定。

随着非核心平台日益增长并被生态系统更多地采用，需要一种方法来减少 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 的开发，请务必加入我们的开放倡议并阅读我们网站上的贡献指南。我们希望未来也能与您见面！