跳转到主要内容

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 来实现相同的桥接原生平台功能的目标。我们需要关于如何做好这一点的更好文档。
  • Brownfield 文档 – 在峰会召开时，将 React Native 集成到原生应用中的官方文档已经过时。此后，团队跟进了适用于 Android 和 iOS 的最新且更简单的文档。
  • Metro Web 的 Tree-shaking – 核心 Metro 团队愿意合并 Expo 团队在该领域的工作。

Native Modules 的 Web API​

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

web-apis

Web API 规范的标准化不仅对 React Native 的发展有利，而且至关重要，并且与我们的多平台愿景和 react-strict-dom 项目非常吻合。Web 通过其规范提供了一个统一的接口，而 React Native 社区模块目前缺乏这种接口。Microsoft 已经确定了大约 200 个重要的 Web API，可以首先为他们支持的平台实施：iOS、Android、Windows 和 macOS。

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

虽然该提案似乎对 React Native 的未来有利，但我们仍在集思广益，讨论下一步的行动方案。我们注意到的一个担忧是 API 的治理，以及它们是否需要与平台实现分开存储在一个单独的存储库中。另一个担忧是，如果特定平台允许 W3C 未指定的行为，则是否会偏离官方规范。我们需要弄清楚如何避免捆绑不必要的模块，例如使用 Babel 插件。更不用说这项计划的范围非常大。

本次会议的结论强化了两个关键点：首先，React Native 社区在尽可能采用 Web 兼容规范方面达成了高度一致。其次，我们需要为如何为不同平台单独维护这些 Web API 实现建立清晰的技术策略。Microsoft 和 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 Modules - 通过将 props 暴露为 jsi::Values 来解除 View 组件的阻塞​

最近，Marc Rousavy 引入了 Nitro Modules 作为创建 Native Modules 的替代方法。Nitro Modules 利用实验性的 C++ Swift Interop，并结合了许多增强功能，可以在某些场景下提高性能。但是，在本次会议期间，我们讨论了 Nitro Modules 和现有 TurboModules 之间涉及的各种权衡。

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

树外平台和 CocoaPods​

树外平台展示了 React Native 的全部功能，我们可以在移动设备、桌面甚至 VR/XR 设备上运行的不同平台之间共享一个 JS 代码库。目前，创建这样一个平台并不是最容易的过程，实际上没有关于如何创建、开发和维护事物的指南。而且 React Native Core 在某种程度上与 Android 和 iOS 平台相关联。未来，我们的目标可能是实现所有平台都得到平等对待，并通过相同的 API 与 C++/JS 核心集成的场景。

oot-platforms

在本次会议期间，不同平台的维护者讨论了问题所在、他们的挣扎以及统一创建和维护新树外平台的过程的解决方案应该是什么。

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

桌面上的 React Native​

来自 Microsoft 的 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 的开发，请务必加入我们的开放倡议并阅读我们网站上的贡献指南。我们希望将来也能与您亲自见面！