跳至主内容

React Native 核心贡献者峰会 2024 回顾

· 1 分钟阅读
Michał Pierzchała
Michał Pierzchała
Head of Technology @ Callstack
Szymon Rybczak
Szymon Rybczak
Software Engineer @ Callstack
Mo Javad
Mo Javad
Head of Mobile (UK) @ Theodo
Steven Moyes
Steven Moyes
Senior Product Manager @ Microsoft
非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →

每年，React Native 社区的核心贡献者都会与 React Native 团队齐聚一堂，共同规划这个项目的未来方向。

去年也不例外——只是稍有不同。我们通常在React Universe Conf（前身为 React Native EU）召开前一天，在弗罗茨瓦夫的Callstack总部会面。2024年，我们吸取了以往经验，将峰会延长至连续两天，以便有更多自由交流的时间。

全体与会者

这一年度传统已成为宝贵的机会：贡献者可以分享见解、表达关切，核心团队能同步规划蓝图，并从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，核心是将 Web API 子集引入 React Native。该方案旨在通过开发者熟悉的 API 提升 React Native 的可扩展性，吸引更多 Web 开发者，并为大量未明确支持 React Native 的现有开源 Web 库提供接入通道。

web-api 讨论现场

标准化 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 计划，旨在缩减核心范围，淘汰过时的 API 和组件。如今，React Native 组件和 API 体系迫切需要新一轮优化整理。

当前存在大量缺乏主动维护的组件（已有更优社区替代方案），以及应被合并以提高可维护性的重复组件。

API 层面，许多 JS 层 API 与原生 iOS/Android 实现强耦合，缺乏真正的平台无关性。例如 Pressable 组件的 android_disableSound 和 android_ripple 属性。理想情况下，React Native 组件应具备最小化的、不绑定特定平台的 API 接口。

随着树外平台（Out-of-Tree platforms）的生态采用率持续增长，我们需要建立机制来缩减 React Native 核心的组件和 API 范围：既减轻核心团队负担，也让树外平台和库维护者能更轻松地保持同步更新。

作为额外红利，这将让 React Native 新手开发者更容易上手，因为他们需要学习的重复组件和"陷阱"更少了。当存在更优质的社区替代方案时，开发者会被引导并鼓励使用这些现成的社区方案。

在本环节中我们讨论了：

  • Lean Core 项目的宏观动机及其对各方（开发者/库维护者/Meta）的益处

  • 来自真实生产环境 React Native 应用的部分组件使用情况汇总

  • 判定哪些组件适合从核心库移除的标准

  • 执行 Lean Core 2.0 的明确行动计划：

    • 组件废弃的高层流程
    • 处理 Meta 内部仍在使用的、但已有更优社区替代方案的组件

后续将组织核心贡献者小组收集更多遥测数据，评估社区替代方案，并起草详细说明变更建议的 RFC 文档。

Nitro Modules - 通过 jsi::Value 暴露属性解除视图组件阻塞​

近期 Marc Rousavy 提出 Nitro Modules 作为创建原生模块的新方案。该方案利用实验性 C++/Swift 互操作技术，包含多项能提升特定场景性能的增强功能。但在本环节中，我们重点探讨了 Nitro Modules 与现有 TurboModules 之间的各种权衡取舍。

尽管 Nitro Modules 具备性能优势，但也存在需要考量的局限性和注意事项。例如使用实验性互操作特性可能带来 TurboModules 中不存在的复杂性或兼容性问题。讨论聚焦于这些权衡点，以及将 Nitro Modules 部分优化方案上游化到 React Native 核心的可能性，这将惠及所有开发者。

树外平台 & CocoaPods​

树外平台（Out-of-Tree Platforms）充分展现了 React Native 的威力——让我们能在移动设备、桌面端甚至 VR/XR 设备等不同平台上共享同一套 JS 代码库。目前创建这类平台并非易事，实际上缺乏关于创建、开发和维护的标准化指导。同时 React Native 核心在某种程度上仍与 Android/iOS 平台深度绑定。未来我们可能致力于实现所有平台平等接入，通过统一 API 与 C++/JS 核心交互的愿景。

树外平台

本环节中，不同平台的维护者们探讨了当前痛点、面临的挑战，以及如何统一树外平台创建和维护流程的解决方案。

另一项议题是 CocoaPods 及未来管理原生依赖项的计划。近期 CocoaPods 团队宣布进入维护模式，不再发布重大功能更新。我们讨论了替代方案的优缺点及迁移路径。

桌面端 React Native​

来自微软的 Steven 和 Saad（react-native-windows 和 react-native-macos 的维护者）主持了本环节，收集贡献者对桌面平台的反馈。议题包括：如何提升 React Native 桌面端采用率（如在 Visual Studio 中提供专属工作流，或将桌面端集成到 Nx 生态），以及如何支持 Expo——这仍是阻碍广泛采用的关键痛点。

macOS 与 Windows 的社区模块可用性存在显著差异，主要源于 iOS 代码大多兼容 macOS，而 RNW 需要专门实现。在为 React Native for Windows 实施新架构的过程中，团队发现 C++ 模块有望实现更深入的跨平台代码共享，这将减轻桌面端适配负担。值得注意的是，社区方面 Software Mansion 正为其热门模块（如 React Native Screens、Gesture Handler 和 Reanimated）添加桌面端支持。

我们至今仍惊叹于短短几天的相聚竟能促成如此丰富的知识共享和创意碰撞。这次峰会上播下的种子，将帮助我们改善并重塑 React Native 的生态系统。

如果您有兴趣参与 React Native 的开发，欢迎加入我们的开源计划并阅读官网的贡献指南。期待未来能与您线下相见！