当我构建第一个 react native 应用程序时，我之前有一些 Web 开发经验。在 ios 和 android 上使用 React 似乎是我技能的自然延伸。
但我很快发现——这是一个艰难的过程——网络开发人员的思维方式并不总是能很好地转化为原生应用程序开发。
以导航为例。在网络上，每个网站通常都会制作自己独特的页面布局。页眉、侧边栏和页脚都是定制的。您可能从一个简单的元素开始，但它只是一个空白画布。您必须使用 JavaScript 和 css 来使其具有功能性和视觉吸引力。
这种定制成为您品牌标识的一部分。如果您的标题看起来像另一个网站的标题，那就感觉很普通。
当我转向本机应用程序开发时，我也带着同样的心态。
我为一切精心设计了自定义组件。我用后退按钮和标题构建了自己的标题。我创建了自定义屏幕转换和动画。我什至自己管理安全区域并跟踪屏幕方向以动画过渡。我精心制作了自定义底部选项卡 – 任何确保我的应用程序看起来与其他人的不同的东西。
没过多久就意识到这是一个错误。
本机应用程序用户期望跨应用程序保持一致的模式。他们对导航等基本 ui 元素的质量也抱有很高的期望。例如，在 iOS 上，用户希望长按后退按钮以返回多个屏幕。如果缺少这一点，体验就会感觉不完整。
那么为什么要重新发明轮子呢？本机组件已经针对该平台进行了优化。我可以简单地使用本机并调整其颜色，而不是从头开始构建自定义标头。更好的是，我可以完全跳过自定义并直接使用 UIKit 组件。用户不会感觉“基本”，而是会欣赏该应用程序如何自然地融入 iOS 生态系统。
以 Apollo for Reddit 等应用程序的成功为例。人们喜欢它，因为它采用了 iOS 的原生设计语言，让人感觉像是该平台的自然扩展。
这与 Web 开发形成鲜明对比。在网络上，您从空白画布开始，自己构建一切。开箱即用的基元通常笨重且没有吸引力。按钮是灰色的。输入具有粗糙的轮廓。您甚至需要重置 CSS 才能获得一致的基线。
Web UI 库的存在就是为了缓解这些挫败感，但它们是一个拼凑的解决方案。相比之下，像 iOS 这样的原生平台具有凝聚力强、制作精美的设计原语。导航、动画、菜单、版式、颜色和图标均由专家精心设计，以创造无缝的用户体验。这些不仅仅是工具——它们是经过数十年完善而形成的设计系统。
我花了太长时间才意识到这一点。一开始我什至都懒得去读苹果的人机界面指南。
早在 2019 年，React Native 应用程序常常让人感觉像是对原生应用程序的高质量模仿。他们看起来很像，但并没有完全感觉到。 React Native 的理念一直是匹配底层平台，但在实践中，许多库依赖于基于 JavaScript 的组件来模仿本机组件，而不是使用真实的组件。
例如，Android 上的 React Native 应用程序经常使用 Material Design 标头，但它们是用 JavaScript 实现的，而不是利用实际的本机标头组件。
作为一名 Web 开发人员，我发现这种抽象很有吸引力。它让我可以完全控制定制。但这种方法常常会导致微妙的不一致，从而降低用户体验。
React Native 开发者并不完全是罪魁祸首。当时，使用本机代码很麻烦，尤其是在使用 Expo 的情况下。添加本机功能通常需要放弃 Expo 并重新配置整个堆栈。具有本机代码的库经常与 React Native 更新不同步，使开发人员不得不处理他们不完全理解的 Objective-C 或 Java 文件。
“基于 JS”甚至成为库的一个卖点，向开发人员承诺他们不必处理原生依赖关系。
JavaScript 和本机代码之间的这种分歧强化了我的网络优先心态。为什么不坚持使用 JavaScript 来完成所有事情？
值得庆幸的是，React Native 生态系统已经发展。如今，您可以使用 swift 和 kotlin 编写原生模块，而配置要少得多。更好的是，Expo 现在支持本机代码。这些改进使得原生优先开发变得更容易，鼓励库接受原生原语。
例如，React Navigation 已转向使用本机组件，优先考虑无缝的用户体验而不是广泛的开发人员定制。
这一转变标志着 React Native 的未来更加光明。随着原生工具变得更易于使用，我们可以构建看起来和感觉都属于其平台的应用程序。
所以，从我的错误中吸取教训。使用该平台的工具并接受其设计理念。最重要的是，在决定打破规则之前先掌握规则。
