by Amanda Bullington

通过阿曼达·布林顿(Amanda Bullington)

我在React Native中构建时获得的经验教训 (Lessons I learned while building in React Native)

When I received an offer for a software engineering role to build an app in React Native, I wasn’t sure what to expect.

当我收到要在React Native中构建应用程序的软件工程职位的邀请时，我不确定会发生什么。

On one hand, it sounded exciting to be able to build a mobile application for iOS and Android using a single codebase. On the other, hearing that companies like Airbnb had tested the platform and ultimately decided against it left me feeling like there would be a fair number of challenges ahead.

一方面，能够使用单个代码库为iOS和Android构建移动应用程序听起来很令人兴奋。 另一方面，听说像Airbnb这样的公司已经对该平台进行了测试，并最终决定反对该平台，这让我感到未来将面临许多挑战。

Now I’m a few months in, and here are some of the lessons I learned along the way.

现在我已经有几个月了，这是我在此过程中学到的一些经验教训。

选择合适的库 (Choosing the right libraries)

One of the first things I learned about React Native is that the choice of third-party libraries is often limited. As a JavaScript web developer, I had a wide choice of libraries that I could customize to various projects.

我从React Native中学到的第一件事是，第三方库的选择通常受到限制。 作为一名JavaScript Web开发人员，我可以选择多种库，可以针对各种项目进行自定义。

React Native libraries are more complex to build. They require a knowledge of native code for iOS and Android to work across platforms. Because of this, there aren’t as many people who develop libraries for React Native.

React Native库的构建更加复杂。 他们需要iOS和Android的本机代码知识才能跨平台工作。 因此，为React Native开发库的人不多。

After some futile searching on GitHub, I ended up choosing most of my app libraries from the React Native Community repo. These are generally the best maintained and almost guaranteed to work with the latest version of React. The Native Directory was another helpful place to quickly search what’s available in React Native.

在GitHub上进行了徒劳的搜索之后，我最终从React Native Community repo中选择了我的大多数应用程序库。 这些通常是维护得最好的，几乎可以保证可以与最新版本的React一起使用。 Native Directory是另一个快速搜索React Native中可用内容的有用位置。

Even within the RN community repo, not all libraries worked out of the box. Sometimes I needed to fork the repo and make a few tweaks of my own. Other times, I needed to downgrade to a version that fixed the particular bug that showed up in my app. Version control is all the more important when there are few libraries and few maintainers.

即使在RN社区回购库中，并非所有库都可以立即使用。 有时我需要分叉仓库，并自己做一些调整。 其他时候，我需要降级到可修复出现在我的应用程序中的特定错误的版本。 当库和维护者很少时，版本控制就显得尤为重要。

适应Flexbox (Getting comfortable with Flexbox)

With more than 10,000 types of devices for Android alone, it can be tricky to build an app that works for all screen sizes. I needed my app to look good on devices as small as the iPhone SE and as large as the Pixel 2XL.

仅使用10,000多种类型的Android设备，就很难构建适用于所有屏幕尺寸的应用。 我需要我的应用在小至iPhone SE和大至Pixel 2XL的设备上看起来都不错。

At first, I tried styling my app by using React Native’s built-in Dimensions class to find the width and height of each screen. Ultimately, this was too complicated to maintain as the app grew. Instead, Flexbox is the key to being able to tackle styling across screen sizes gracefully. A quick run through of the Flexbox Froggy tool is a good way to get up to speed.

最初，我尝试使用React Native的内置Dimensions类来设计应用程序的样式，以查找每个屏幕的宽度和高度。 最终，随着应用程序的增长，这太复杂了，难以维护。 相反，Flexbox是能够优雅地处理各种屏幕尺寸样式的关键。 快速运行Flexbox Froggy工具是加快速度的好方法。

Flexbox didn’t solve all my styling problems. I still encountered quirky screen sizes that needed their own styling solutions like the SafeAreaView for the iPhone X series. I also needed to use conditional statements for different iOS and Android styling on many screens. But overall, it’s a great tool for designing apps in React Native.

Flexbox并不能解决我所有的样式问题。 我仍然遇到奇怪的屏幕尺寸，需要他们自己的样式解决方案，例如iPhone X系列的SafeAreaView 。 我还需要在许多屏幕上针对不同的iOS和Android样式使用条件语句。 但总的来说，它是在React Native中设计应用程序的绝佳工具。

将其关闭然后再次打开 (Turning it off and back on again)

Once I installed a new third-party library and ran react-native link, I often ran into the “undefined is not an object” error. React Native is known for its non-descriptive error messages. It took me a while to figure out what this meant. At first, I thought there was something wrong with the library. Or that it didn’t work with the version of React Native I had installed.

安装新的第三方库并运行react-native link ，我经常会遇到“未定义不是对象”错误。 React Native以其非描述性错误消息而闻名。 我花了一段时间才弄清楚这是什么意思。 起初，我认为图书馆有问题。 或者它与我安装的React Native版本不兼容。

Then, deep in a GitHub issue thread for one particular library, I found this comment that finally shed light on why none of my libraries were working smoothly.

然后，深入到某个特定库的GitHub问题线程中，我发现此评论最终阐明了为什么我的所有库都无法正常工作。

Like many developers, I had gotten into the habit of simply reloading my project while running react-native run-android or react-native run-ios. Hot-reloading is great for saving time while making tiny styling tweaks to the app and checking out screens. However, it does not help integrate new libraries into the app. My new libraries wouldn’t work until I closed all my simulators/emulators, disconnected my devices, and re-ran npm start to restart the Metro bundler.

像许多开发人员一样，我养成了在运行react-native run-android或react-native run-ios时仅重新加载项目的习惯。 热重装非常适合节省时间，同时对应用程序进行细微的样式调整并签出屏幕。 但是，它无助于将新库集成到应用程序中。 在关闭所有模拟器/仿真器，断开设备连接并重新运行npm start以重新启动Metro捆绑程序之前，我的新库将无法工作。

In other words, I needed to turn everything off and back on again to smoothly integrate third-party libraries without misleading error messages.

换句话说，我需要关闭然后重新打开所有内容，以流畅地集成第三方库而不会误导错误消息。

在没有调试器的情况下工作 (Working without a debugger)

As a web developer, I was practiced at searching for bugs in the Google Chrome debugger. In React Native, it only took a few weeks before I lost my ability to debug in Chrome.

作为一名网络开发人员，我曾练习过在Google Chrome调试器中搜索错误。 在React Native中，只花了几周的时间，我就失去了在Chrome中进行调试的能力。

One of the constraints of my app was that I needed to use Realm as my primary database. However, Realm has a frequently reported issue where it cannibalizes the Chrome debugger, making it impossible to use. I needed to find a different solution.

我的应用程序的限制之一是我需要使用Realm作为主数据库。 但是，Realm有一个经常报道的问题 ，它蚕食了Chrome调试器，使其无法使用。 我需要找到其他解决方案。

React Native has a built-in debugger where you can log console.logs to the terminal with react-native log-android or react-native log-ios. While this works well on Android, I ran into issues using this debugger for iOS. I began to adopt an Android-first approach to development, where I would build and test everything on Android to easily access console.logs, then make tweaks to the iOS version as needed. I also invested in writing better error messages within my app, which benefited both my users and me.

React Native有一个内置的调试器 ，您可以使用react-native log-android或react-native log-ios console.logs登录到终端。 虽然这在Android上运行良好，但使用iOS调试器时遇到了问题 。 我开始采用Android优先的开发方法，在该方法中，我将在Android上构建和测试所有内容以轻松访问console.logs，然后根据需要对iOS版本进行调整。 我还投资于在应用程序中编写更好的错误消息，这对我和我的用户都有利。

I also experimented with using XCode and Android Studio to debug, but I ultimately found my Android-first approach to be the easiest solution with the least amount of screen switching.

我也尝试过使用XCode和Android Studio进行调试，但是最终我发现以Android为先的方法是最简单的解决方案，并且屏幕切换次数最少。

尽早进行生产构建 (Running production builds early)

Experienced React Native developers have told me that they rarely run into any issues in production mode that they didn’t already see and solve for in development. That wasn’t my experience. When I ran my production builds on physical devices, I was able to catch a few errors that I hadn’t spotted before.

经验丰富的React Native开发人员告诉我，他们很少在生产模式中遇到他们尚未在开发中看到并解决的问题。 那不是我的经验。 当我在物理设备上运行产品时，我能够捕捉到一些以前未发现的错误。

One example was navigation. Setting up navigation in a mobile app was tricky for me to wrap my head around at first, and I needed to make a few changes to the way I set up my react-navigation library to deliver data to the user at the right time. Using a physical device let me simulate all the ways a user might run through my app (i.e. when they would move to a new screen vs. pressing the back button) and set up navigation accordingly.

一个例子是导航。 首先，在移动应用程序中设置导航对我来说很棘手，我需要对设置React导航库的方式进行一些更改，以便在正确的时间将数据传递给用户。 使用物理设备，我可以模拟用户可能会通过我的应用程序运行的所有方式(即，当他们移动到新屏幕而不是按下后退按钮时)并相应地设置导航。

Another issue that I found in production involved dangerous Android permissions. Newer Android phones require more explicit permission requests, and once I tested on a physical device, I realized that my app’s photo gallery needed these permissions to load correctly.

我在生产中发现的另一个问题涉及危险的Android权限 。 较新的Android手机需要更明确的权限请求，并且在物理设备上进行测试后，我意识到我的应用程序的图片库需要这些权限才能正确加载。

结论 (Conclusion)

React Native is well-documented and relatively quick to learn, especially if you already know React. It’s immensely satisfying to build a mobile application that works across both iOS and Android with a single codebase.

React Native的文档资料丰富，而且学习起来相对较快，特别是如果您已经知道React。 使用单个代码库构建可同时在iOS和Android上运行的移动应用程序非常令人满足。

The challenges I ran into above were some of the trickier parts — but overall, there weren’t any huge hurdles to developing an app in React Native. Mostly, I needed to wrap my head around the quirks of mobile development and get comfortable with some of the awkward error messages. Now that I’m past these initial learning curves and settled on an Android-first approach, development is much faster.

我在上面遇到的挑战是一些棘手的部分-但总的来说，在React Native中开发应用程序并没有很大的障碍。 通常，我需要全神贯注于移动开发的怪癖，并适应一些尴尬的错误消息。 现在，我已经超越了这些最初的学习曲线，并选择了Android优先的方法，开发速度将大大提高。

Would I develop in React Native again? Absolutely.

我会再次在React Native中进行开发吗？ 绝对。

翻译自: https://www.freecodecamp.org/news/lessons-i-learned-while-building-in-react-native-917cb7bb5993/