Lessons Learned about React-Native Development

For a lot of React web developers React-Native may offer the first opportunity to create native-like applications and they may find the ecosystem is an entirely different beast. Other developers may have used Ionic, which is a different solution to the same problem that React-Native attempts to solve. However, Native applications have an entirely different set of problems and so does React-Native. For most the opportunity to learn from other’s mistakes should be incredibly helpful.

Naturally any first trip into a new ecosystem and/or framework will lead to plenty of opportunities for learning -- at least it did for me. As with any personal experience, the advice that follows may not apply to everyone or every project.

Don’t Use a Boilerplate

Using a Boilerplate is a mistake nearly every new developer makes, I understand the allure of having a lot of decisions and code already done for you but, I still don’t agree with the decision. And with that said, I definitely made the same mistake on my first big React-Native projects. Now let me tell you the issues with the boilerplate that I ran into.

Misuse

When you spin up most boilerplates, they come pre-loaded with whatever libraries, plugins, and architecture decisions worked best for whomever made it. Now some of those decisions may make sense for your project, but some of them probably won’t. You may end up using libraries that aren’t needed and wind up not using them correctly because the decision that led to it isn’t overly obvious.

Lack of Learning Opportunities

The first time using a new framework presents plenty of opportunities to learn more about it, one being when to reach out for a plugin/extension to solve some problem over just using the tools the framework/language give you to solve it. When you roll with a boilerplate you deprive yourself of experiencing what problems lead to what tool being added.

Over Complication

Boilerplates try to be generic so that they can be applied to as many different scenarios as possible, but they still always come with their own architectural decisions. The more general a boilerplate is made, the less likely it is that it is a perfect fit for your specific project. While it may be a good fit for most, it could be over-engineered for yours. Then you have a decision to make, do you just roll with the complicated project, or do you try to remove the parts of the boilerplate that you don’t need? Either way your development process probably got a little bit more complicated.

Don’t Add Libraries You Only Think You’ll Need In The Future

This one piggybacks off of the last mistake. In a nutshell, installing a bunch of libraries up front just because you could possibly need them in the future is an easy mistake. Just because you think you might possibly need a plugin for keeping secrets hidden doesn't mean you necessarily need it right this moment. It also makes keeping your dependencies up to date more difficult.

This one can also lead to some over complication, adding too many things up front may lead to using too many plugins that weren't even needed in the first place. Over complication can easily lead to frustration especially when someone is new in an ecosystem.

Don’t Wait Until It’s Too Late To Write Tests

Now this one may seem obvious to some readers, but it's a lesson plenty of developers have to learn the hard way. The benefits of testing and the various approaches of how to develop with tests should be relatively well known, and this isn't the place to list them all out. Thankfully writing tests for a React-Native project is very low friction and can save a lot of hair pulling in the future.

The longer that a project goes untested the more daunting a task it seems to add them, which only compounds the problem and leads to more untested code. Waiting until the end of a project to implement tests is only shooting yourself in the foot.

Don’t Decide on a Router with Little to No Research

The router that is chosen at the start of a project is very important, it dictates the structure and maybe even the design of the application. It can lead to further decisions about what libraries are needed to achieve things like “Tab Bar” navigation or” Drawers”. There are a plethora of router libraries to choose from in the React-Native ecosystem. Before deciding take a second to look at how active they are, what they use under the hood, and what people are saying about them.

Once you have decided on a router try and stick with it, because ripping the router out and adding another one while not breaking anything in the app is going to be impossible.

Don’t Ignore Cocoapods Because It’s New To You

All of you iOS devs out there can skip this section.

Now those of you that are left, you will have to learn to use XCode and you will probably have a love/hate relationship with it. Now that being said, cocoapods can take away some of the pain that is manually adding iOS dependencies using XCode. Android has gradle, and iOS has cocoapods… Use them.

Check out this guide to setup cocoapods

Don’t Forget to Account for the Keyboard

While a relatively small tip, this one has caused a few headaches for me in the past. When developing on iOS using Simulators the software keyboard won't show up because you have a hardware keyboard you are using to type. This may seem nice but can cause some issues with styling, the keyboard may be covering up some critical button leaving no way to advance or go back to the previous screen (yes that one happened to me).

To turn on the software keyboard on a simulator go the status bar then click Hardware > Keyboard > Toggle Software Keyboard (⌘ K)

Debugging

Debugging on React-Native probably warrants its own blog post, so for now I’m going to leave some small tips.

Use Stetho to Debug XHR

On Android you can easily setup a plugin called Stetho that allows you to debug XHR requests in the chrome debugger, which is normally not possible. Without it debugging requests can be quite a pain.

Check out how to setup up Stetho on Android

Learn to Love console.log and alert

Like it or not a quick an easy way to log the value of something or see if some lifecycle method is firing is still just to add a quick console.log, or even an alert call if you don't want to fire up the remote js debugging.

Quick Tips

Not everything I’ve run into is a huge game changing piece of advice, some stuff is small and only needs to be kept in the back of one's mind.

• Make sure to also test on physical devices, not just simulators
• Make sure you periodically test on each platform, don't just stick to one and hope for the best.
• React-Native has a monthly release cycle, make sure to plan on migrating using react-native-git-upgrade monthly to stay up to date. Trying to jump multiple versions at once is going to be much more difficult.
• Pay close attention to forms/inputs
  • Use the correct keyboard type (e.g. phone-pad vs text)
  • Use a return key text to hint at what the button will do
  • Turn Autocorrect and Auto Capitalization on/off accordingly
  • Password fields should have secure-text entry

Overall, the first React-Native project you build should be a pleasant experience even if you run into some hiccups along the way. Beyond this post there are more pitfalls that others have surely run into. Always be diligent in seeking and sharing advice with fellow developers.