跳到主要内容

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​

本次会议专门讨论了微软的 RFC，该 RFC 围绕着将 Web API 的子集引入 React Native 的想法。它旨在通过利用熟悉的 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 这样的 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 互操作，并融入了一系列增强功能，可以在某些场景中提高性能。然而，在本次会议中，我们讨论了 Nitro 模块和现有 TurboModules 之间涉及的各种权衡。

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

非核心平台和 CocoaPods​

非核心平台展示了 React Native 的全部强大功能，我们可以在运行于移动设备、台式机甚至 VR/XR 设备的不同平台之间共享一个 JS 代码库。目前，创建这样的平台并非易事，实际上，并没有关于如何创建、开发和维护的指导方针。此外，React Native Core 在某种程度上与 Android 和 iOS 平台绑定。未来，我们可以追求所有平台一视同仁，并通过相同的 API 与 C++/JS 核心集成的场景。

oot-platforms

在本次会议期间，不同平台的维护者讨论了存在的问题、他们遇到的困难以及统一创建和维护新非核心平台流程的解决方案。

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

桌面版 React Native​

来自微软的 react-native-windows 和 react-native-macos 维护者 Steven 和 Saad 主持了一场会议，听取并收集了与桌面平台相关的贡献者反馈。讨论的主题包括探索如何提高 React Native for Desktop 的采用率（例如在 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 的开发，请务必加入我们的开放倡议并阅读我们网站上的贡献指南。我们也希望将来能与您面对面交流！