React Native Pitfalls
There are a lot of collections of anti-patterns for React and different app’s state managers like Redux and MobX (e.g. react-bits), but I haven’t seen a lot of advises for React Native developers. In this post I’ve collected some tips, based on my and my colleges’ experience.
I’ll be thankful for a feedback and your experience in comments.
Be careful with React Native updates
React Native releases are frequent enough (once per month) and usually they contain breaking changes. Try to use up-to-date React Native (react-native-git-upgrade plugin will help you), but be confident, when you decide to update it, because probably you’ll spend a couple of hours on testing and repairing everything.
… and with libraries selection
Configuring a React Native package for additional functionality may appear time-consumable. Especially if we talk about something platform specific (e.g push notifications or in app purchases). Look for different alternatives, read through installation guides and issues on GitHub, try to install a few packages and check out, how they work. Never make a decision about a package, depending only on one platform.
Do not be afraid of native code
React Native has a nice API for configuring communication between JavaScript and Java / Objective C. You can create bridges between JavaScript and native modules, enable messaging between two sides of an app, create your own components. Sometimes just a few lines of native code can save you from dozens of unneeded JavaScript.
Do not estimate Android & iOS equally
Personally I spend much more time on configuring iOS apps. Other developers have other experience. The conclusion is that you won’t probably spend 50% of your time on iOS and other 50% on Android.
Develop Android and iOS in a parallel
React Native is not a ‘write once, run everywhere’ tool. Your apps are native and that’s awesome, but Android and iOS are different platforms, with different guidelines and components. Sometimes your components will look differently and some of your logic will work differently. So develop and test both versions in parallel.
Test on a device from the day one
Emulators are nice, but use devices, especially on Android because of variety of screen sizes, OS versions is use, etc.
It won’t be iOS/Android only story
Sometimes people pick React Native for developing an app only for one platform (yep, seriously). But in this case, you’ll definitely will appear sitting in the office at some evening configuring the app you was not thinking about for a long time. So do not delete your ios and android folders and for the whole development process be sure, that if you select a library or develop a solution, that won’t work on one of the platforms, it will become your technical debt later.
Do not rely on JavaScript’s single thread
It’s still single-threaded JavaScript. Do not overload it with heavy calculations, animations and heavy data sync. Delegate them to native threads. For this you can use one of ServiceWorker polyfill (e.g. react-native-workers). For animations I recommend to useNativeDriver: true property of Animated module, it will put all the calculations to native thread.
I hope this advises will help you to create and launch better applications with less pain and time spent. If you had different experience and you do not disagree with my post at some points, please share your opinion and comments! Thank you.