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

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

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

这一年度传统活动为贡献者提供了宝贵的机会，让他们能够分享见解、表达关切，同时也让核心团队得以分享计划，并从React Native生态系统的关键贡献者（包括合作伙伴公司、独立库作者和朋友们）那里收集反馈。

我们将峰会分为两个主题板块，涵盖以下话题：

• 版本发布

• 新架构之后的发展方向

• 原生模块的Web API规范

• LeanCore 2.0

• Nitro模块：通过将属性暴露为jsi::Values解锁视图组件

• 外部平台与CocoaPods

• 桌面端的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来实现桥接原生平台功能的相同目标。我们需要更好的文档来指导如何做好这件事。

• 混合开发文档：在峰会召开时，将React Native集成到原生应用的官方文档已经相当陈旧。从那以后，团队已经更新了适用于Android和iOS的最新、更简洁的文档。

• Metro web的摇树优化：Metro核心团队愿意合并Expo团队在这一领域的工作成果。

本次会议专门讨论了微软提出的RFC（请求评论），其核心思想是将一部分Web API引入React Native。这旨在通过利用开发者熟悉的API，提高React Native的可扩展性，并吸引更多Web开发者，同时开放访问大量现有的、没有明确React Native支持的开源Web库。

标准化Web API规范不仅有益，而且对React Native的发展至关重要，这与我们的“多平台”愿景以及react-strict-dom项目非常契合。Web通过其规范提供了统一的接口，而这正是React Native社区模块目前所缺乏的。微软已经确定了大约200个基本的Web API，可以首先在他们支持的平台（iOS、Android、Windows和macOS）上实现。

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

虽然该提案对React Native的未来似乎很有益处，但我们仍在思考接下来的步骤。我们注意到的一个问题是API的管理，以及它们是否需要与平台实现分开存放在不同的代码库中。另一个问题是，如果某个特定平台允许W3C规范未规定的行为，可能会出现与官方规范的分歧。我们还需要考虑如何避免捆绑不必要的模块，例如通过Babel插件。更不用说，这个计划的规模相当大。

会议得出的结论是，我们都希望将更多的Web标准集成到React Native中。微软和Callstack可以合作完善最初的RFC，并作为社区项目，为少量API提供概念验证实现。这样，在扩大范围并获得React核心团队的正式认可之前，我们可以逐步验证设计和开发者体验。

会议结论强调了两个关键点：第一，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这样的属性。理想情况下，React Native组件应该具有尽可能小的、不依赖于任何特定平台的API表面。

随着外部平台的不断发展并在生态系统中得到更广泛的应用，需要找到一种方法来减少React Native核心的组件和API表面，减轻React Native核心团队的负担，同时也让外部平台和库的维护者更容易跟上更新。

另外，这也会让初学者更容易上手React Native，因为重复的组件和需要学习的“陷阱”会更少。在社区中有更好替代方案的情况下，可以引导并鼓励开发者使用这些方案。

在会议期间，我们讨论了：

• Lean Core的高层动机以及对相关各方（开发者、库维护者、Meta）的好处

• 一些实际生产中的React Native应用使用组件的汇总情况

• 确定哪些核心组件可被移除的标准

• 执行Lean Core 2.0的明确行动计划，包括：弃用的高级流程；处理Meta内部使用的组件在社区中有更好替代方案的情况。

下一步，一组核心贡献者将收集更多的遥测数据，评估社区替代方案，并编写一份RFC，详细说明提议的变更。

Nitro模块：通过将属性暴露为jsi::Values解锁视图组件

最近，Marc Rousavy推出了Nitro Modules，作为创建原生模块的一种替代方法。Nitro Modules利用实验性的C++ Swift互操作功能，并融入了一系列增强功能，在某些情况下可以提高性能。然而，在本次会议中，我们讨论了Nitro Modules与现有的TurboModules之间的各种权衡。

虽然Nitro Modules提供了一些性能优势，但它们也有局限性和需要考虑的问题。例如，使用实验性的互操作功能可能会带来TurboModules中不存在的复杂性或兼容性问题。我们的讨论聚焦于这些权衡，以及将Nitro Modules的一些改进合并到React Native核心中的可能性，这可以让开发者受益于更高效的模块。

外部平台与CocoaPods

外部平台充分展现了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需要定制实现。在为Windows开发React Native新架构的过程中，团队发现C++模块有潜力实现更多的跨平台代码共享，有望减轻针对桌面平台开发的负担。值得注意的是，在社区层面，Software Mansion正在为他们最受欢迎的模块添加桌面端支持，如React Native Screens、Gesture Handler和Reanimated。

我们仍然惊叹于，仅仅几天时间、每天几个小时的交流，就能带来如此多的知识共享和思想碰撞。在这次峰会上，我们为一些计划埋下了种子，这些计划将有助于我们改进和重塑React Native生态系统。

如果你有兴趣参与React Native的开发，请务必加入我们的开源计划，并阅读我们网站上的贡献指南。我们也希望未来能与你线下相见！

总结

本文回顾了2024年React Native核心贡献者峰会的讨论成果，涵盖多个重要议题。在版本发布方面，探讨了发布流程、频率，以及减少破坏性变更和加强兼容性沟通的方法。新架构后续发展聚焦于Web兼容性、核心API稳定、旧架构支持、第三方库及相关文档等问题。

Web API for Native Modules议题中，微软提议引入部分Web API，虽有好处，但在API管理、规范一致性及模块捆绑等方面存在挑战，计划由微软和Callstack先进行小规模概念验证。LeanCore 2.0旨在清理React Native核心的过时API和组件，减轻核心团队负担，后续核心贡献者将收集数据并制定改进方案。

Nitro Modules与TurboModules的权衡成为会议焦点，会议探讨了将Nitro Modules部分改进融入React Native Core的可能性。Out-of-Tree Platforms & CocoaPods环节讨论了创建和维护外部平台的难题，以及CocoaPods进入维护模式后的替代方案。

桌面端React Native则聚焦于提升其在桌面平台的应用率，解决社区模块可用性差异和对Expo的支持问题。这次峰会促进了知识共享和思想交流，为React Native生态系统的改进和重塑奠定了基础 。

https://reactnative.dev/blog/2025/02/03/react-native-core-contributor-summit-2024