When choosing the React Native framework, it is expected that developing one application for two platforms will take half the time than developing two applications. But in the end, it turns out that development takes just as much (if not more) due to the complexities hidden under the gloss and marketing.
React Native: Brief Review
React Native is, in fact, a really good product of Facebook. It adapts JavaScript for mobile development. This is achieved by the fact that it uses several assemblers to build projects – Metro Bundler, which interprets the JS code and represents the resources and the collector of the target system. In theory, a React-Native app should be pretty easy to run. The React-Native run-android command includes the metro bundler and builds the application for all connected android devices and emulators.
Difficulties that can occur while working in React Native
Now, I am going to light up some React Native limitations that Facebook doesn’t want you to know.
In reality, it turned out that even at the beginning stage there are difficulties. At the very start of the project, the error “Unable to download JS bundle” can constantly appear, which means that the bundler can not translate the code into native. As it turned out later, it did not start. StackOverflow confirmed the guesses and suggested that it is worth starting the bundler in a separate thread using the react-native start command. This allows you to restart the bundler only if the package.json has changed, so the procedure doesn’t slow down development so much.
Package.json is a file that contains a set of external modules for an application. Npmjs.com hosts a large number of different libraries for React Native that extend functionality and simplify the development. Many libraries (for example, firebase) use native functions, and therefore must be linked directly to the native code. To do this, use the react-native link <library-name> command, which should set up these links with the native code.
Due to the fact that all libraries are written at different times, they use different versions of the SDK and require a different approach. Sometimes it happens that libraries are incompatible with each other, or the latest version of a library turns out to be experimental, and the developers themselves advise to downgrade to the penultimate version. Quite often a link does not configure all required dependencies. So, for the aforementioned firebase, you need to add a lot of additional libraries in the native code, connect various external repositories, modify mainApplication.java (and this is only for Android!). For firebase there is a fairly clear instruction for performing these actions, but for other libraries it is not always present.
After the links to the native code are set up, you can build the project with the hope that the linked library will work. When assembling, it is worth remembering that if you get an error, then you should make sure that it arose precisely because of your actions, and not because of a collector error. For complete confidence, it is worth performing the following sequence of actions:
- rmdir node_modules / s / q && npm cache clean-force && npm i
This command will delete the node_modules folder and then download it again. This is one of the most time consuming tasks, so you should rarely use it. On some projects, node_modules can take up to several gigabytes of hard disk space, and therefore reinstalling will take time.
- rmdir android / app / build / s / q
During development, it was noticed that often a bad build is a consequence of the fact that the builder cannot create (or delete) a folder from the debug directory. This action solves the problem that React cannot delete the folder on its own. But at the same time, generating files for this folder from scratch will again take additional time.
- react-native run-android
Install the app on a connected device or emulator. Most build errors happen here, and some of them are understandable, but some are rather irrational and are “cured” by restarting the entire process.
Debugging problems
The React Native debugger has more than launch issues. Correcting errors found as a result of a test is also a painful process. In React Native, JS code is translated into native code, but during translation it is obfuscated. So if you don’t want to see errors like “null pointer exception in zzz.yyy ()”, then you need to use the built-in debugger, you can’t just read the exceptions in logcat. In case of an error, the debugger shows a red “screen of death” with its description, more or less nudging towards the path of fixing. But there are problems with this part too.
This may be due to the fact that you installed the library incorrectly, or if your imports have incompatible dependencies, or something went wrong in the native code, and React is trying to catch the error. Each mistake is individual and resolved in an extremely different way. It’s good that StackOverflow exists and at least some kind of debug mode.
Perhaps the worst case scenario is when the application breaks in random places, only in the production version and without any logs from React Native. Example: after installing the release version of the application on the phone, it “works for a while”, and then “turns off without error or warning at a random moment”. Moreover, the error is not reproduced on all devices.
Conclusion
Remember, React Native is a relatively young technology. React Native has been making us happy for more than two years now, releases are released once a month, but may be accompanied by backward incompatibilities in the code.
Frankly speaking, I really like the React Native Development despite the stated problems that Facebook will never mention. However, don’t be afraid to develop in React Native – as a result, you will get a mobile application for different platforms using one JavaScript.
