React Native 开发者调查：开发者体验有待提升

React Native 团队最近进行了一项面向 React Native 开发者的调查，问题是：“React Native 有哪些东西是你不喜欢的”？绝大多数开发者都将开发者体验（包括调试）作为首要槽点。另外，社区服务和文档也是痛点。

React Native 团队最近进行了一项面向 React Native 开发者的调查，问题是：“React Native 有哪些东西是你不喜欢的”？绝大多数开发者都将开发者体验（包括调试）作为首要槽点。另外，社区服务和文档也是痛点。此外，很多开发者希望 React Native 的应用程序编程接口（API）能够覆盖到经常发生的用例，比如 SVG。一些开发者还指出，React Native 还要不遗余力地实现承诺，即为开发类原生应用程序提供无缝、跨平台的开发工具。

大多数参加问卷调查的开发者对升级时所做的大量工作和所花费的时间表示遗憾。Jan Hesters 解释说：

从一个版本升级到另一个版本很困难，需要做很多工作。特别是当你落后了几个版本，不得不手动从当前版本升级到最新版本。

开发者还指出调试体验太差了。例如，Sebastien Lorber 表示：

我不喜欢的一点是，我们通常很难找到发生异常的根本原因。Chrome 调试器控制台中的堆栈跟踪通常指向 ExceptionManager，而不是原始位置，这导致调试非常耗时。componentDidCatch 并不会带来真正的帮助。

开发者还指出，工具有可能是 React Native 需要做出改进的另一个方面：热重载并不总会有效，样式表可能还有优化的余地，一些工具会发出太多的警告或神秘的错误。过时的依赖项可能构成障碍，使用 Cocoa 需要做大量的工作。Tycho Tatitscheff 详细地描述了这个问题：

Cocoapod 没有得到很好的支持，升级时经常会出现故障。中断非常常见，以至于 @orta 构建了一个插件来自动修复 React Native 的问题：https://github.com/orta/cocoapods-fix-react-native。

Cocoa 是苹果的原生面向对象应用程序编程接口。CocoaPods 是 Swift 和 Objective-C Cocoa 项目的依赖项管理器。对于 iOS、tvOS 和 watchOS，也有一个类似的 API，叫作 Cocoa Touch。

一些 Windows 开发者对他们平台上糟糕的开发者体验表示失望。Attila Szeremi 说：

在这些平台上，React Native 的开发者体验是很糟糕的。文件监视器似乎对文件的变更不太敏感。最糟糕的是，热重载通常只在前五次左右有效，然后就完全卡住了，我不得不一遍又一遍地重新启动捆绑器。

一些开发者甚至建议用 Swift/Kotlin 替代 JavaScript 作为 React Native 开发语言。Ilja Daderko 列举了这样做的一些优点:

我确信这个问题会经常出现，并且我知道用这些语言重写 React Native 应用程序所需要的工作量，但是我发现 Swift 和 Kotlin 对于熟悉 JavaScript 的人来说会更友好。由于 Swift/Kotlin 的学习曲线不像 ObjC/Java 那么陡峭，这可能会带来更多的 OSS 贡献和使用 JS 开发的自定义原生模块。

开发者认为 React Native 团队缺乏对社区的参与，这会导致 Github 上的问题响应时间变慢，并且无法对 PR 做出及时响应。这可能会阻碍开发者对 React Native 开源项目做出贡献。事实上，一些开发者认为贡献过程太过复杂了。一些开发者认为，对社区缺乏支持也造成了总体不确定性和对 React Native 未来缺乏信心。

在文档方面，开发者希望能够获得更多有关常见故障或已知问题的帮助信息。开发者给出了一个具体的例子：

要知道如何正确配置 KeyboardAvoidingView 几乎是不可能的，因为文档对何时使用什么行为的描述非常模糊，也因为它在其他环境中的用法不一样。

我觉得解决方案可能是提供更好的文档，或者采用类似于 response -native-keyboard-aware-scroll-view 的策略：

https://github.com/APSL/react-native-keyboard-aware-scroll-view

Van der Auwermeulen Grégoire 举了另一个例子：

在 JS 线程中桥接 ReactJS 生命周期事件时通常会出现这样的问题，因为与 Native 生命周期事件不一致。我们需要更多有关高级和桥接问题的文档。

虽然开发者知道已经有针对初学者的指南，但仍然需要针对库开发者的特定文档，例如如何处理 React Native 中的高级或隐藏特性，或者如何度量和优化性能。

在 React Native 的 API 表面方面，一些开发者希望看到更多由第三方库提供并已集成到核心的一些功能。例如 SVG 图像、导航、视图回收、推送通知、相机、视频、音频、指纹、基于动作的界面。

其他开发者认为 React Native 无法为用户提供类似于原生的开发体验。启动时间仍然是区分真正的原生应用程序和混合应用程序（如使用 React Native 开发的应用程序）的关键因素。还有一些人表示，React Native 也未能实现跨平台的承诺。Adam Burdette 说：

Android 仍然是二等公民。很多问题只在 Android 上出现，但在 iOS 上却运行良好，所以很多开发者在开发过程中总是忘了会在 Android 上出现问题。

例子：

{0 &&}会导致 Android 崩溃。任何非预期的错误值都会导致 Android 崩溃，而且不会出现错误屏幕。你必须确保返回的是一个布尔值。iOS 在这方面处理得很好。而在 Android 上，你不能指定 flex 的属性，否则应用程序会在切换 secureTextEntry 时会崩溃，这个问题已经存在多年了，我敢肯定还有很多其他的例子。但 Android 应该是未来开发的主要焦点，以便更好地支持跨平台。

React Native 开发者提到的小痛点与 UI 有关：样式和样式不一致、zIndex 不一致、自动滚动、倒排列表或图像维度。

本文内容的主要来源是一个Github Issue，在这个问题中，React Native 团队邀请开发者列出与他们使用 React Native 经验相关的抱怨清单。我们分析了 81 个答案，收集了 5486 个“赞”，并将其分为 6 个类别。这些类别按照喜欢程度的递减顺序排列：开发和调试、社区投入、文档、API、效率、UI。

React Native 是一个使用 JavaScript 和 React 开发原生移动应用程序的框架。与 React 类似，开发者将用户界面描述为组件树。与 React（使用 React DOM 作为渲染器）不同，组件树是使用移动设备的原生 API 来渲染的。在 iOS 上，这意味着 Native 组件会通过真实的 UI Views 来渲染，而在 Android 上，它们通过原生 View 来渲染。JavaScript 层和 Native 层通过一个叫作桥的东西进行通信。

针对移动平台的开发者有一组可用的技术栈。应用程序通常分为三类：移动 Web 应用程序、混合应用程序和原生应用程序。原生应用程序是指使用相应的技术为特定的平台开发的应用程序，并安装在计算设备上。Web 应用程序是使用 Web 技术开发的，可以通过浏览器在多个平台上使用。混合应用程序结合了原生应用程序和 Web 应用程序的元素。它们通常是跨平台的，同时使用独立于目标设备的自定义技术集进行开发。

用于混合应用程序开发的框架包括 React Native、Flutter、Xamarin 或 Iono，等等。

查看英文原文：React Native Team Surveys Developers’ Pain Points