React Native in terms of mobile developer
The article is focused on iOS and android developers who are already quite well versed in their field and are looking in the direction of React Native.
When I first learned about React Native, I took it as an excuse for web developers to invade my territory ( never! ) And at the same time spoil a well-working crash-free-60-fps product.
Negation
Javascript in mobile app? Only a couple of libraries came to mind using JavaScriptCore on iOS (the same libraries caused 90% of the crashes of applications that were used) and hybrid applications of the “old model” (well, this is generally atas).
Hybrid applications gave hope until you try them, and then you start to run away from them headlong and as far as possible.
Recalling the unsuccessful attempts to master Xamarin 3 years ago, I quickly abandoned the idea of using React Native.
It is worth noting that I always happily perceived new ways of writing native applications (from ObjC to Swift, from Java to Kotlin, from Eclipse to Android Studio). For many years I have been involved in iOS and android development as a hobby and professionally. After switching to a new language (within one OS) or IDE, I rarely returned to the previous one. It would seem React Native - the logical next step, another new step up. Or is it a step back?
Anger
Why should I teach a simplified version when I already know how to do it “for real”?
I still had to find an answer to this question when the company set the task of completely redesigning one of the applications (currently only available on iOS) and releasing it on android.
How to do two things at once and write less code? Prompt solutions like: thin client, C libraries with a call from Swift / Kotlin code, React Native?
React Native looked quite promising because of the ability to make libraries and then use them on three platforms at once (iOS / android / web).
Bargaining
It is promising for anyone, but not for me. I certainly was not happy with this turn. I felt that I was at the peak of the ability to develop iOS and android and then I was asked to throw away all this knowledge, as if I am a fresh graduate and I have 0. I doubted that with React Native you can create a quality product.
Depression
Doubt was reasonable. Main problems:
- a decent amount of crashes in the core React Native;
- methods that work only on one platform (docks indicate that they work everywhere);
- incomplete description. Just look at the React Native dock builder .
The main hidden problem: the internal block in my head, which prevented me from seeing the pros behind a bunch of minuses.
Adoption
And of course React Native is not only a minus. There are a lot of good things; it is written much easier and works out of the box better than the same on specific platforms.
If we ignore the obvious problems, such as falls and scanty docks, here are examples of what had to be faced:
Javascript
No wonder. This is the first with which you have to go hand in hand through blood, sweat and tears.
When I began to recall my previous experience of a frontend developer (I was involved in web sites before mobile applications), I started Vietnamese syndrome: Johnny, JavaScript surrounds us!
If you decide to write applications on React Native, then I recommend to take one of the latest JS courses. It is not necessary that they be by React or React Native.
In the past few years, with the release of the ES6, ES7 and ES8 standards, the way of writing code has changed a lot.
And he became very personal .
Static check
In the first months, there is a great lack of a static analyzer, which is available in all native mobile languages.
There are various utilities that smooth its absence by performing some functions.
Layout elements
The biggest challenge here will be for beginners iOS developers.
This challenge is the lack of a visual interface editor.
Everything is done in the code using JSX markup. Technically, this markup is optional, it helps to see the hierarchy of components. Android developers will be at ease, noticing similarities with XML.
At the same time, there is a clear view of the views and the potential for reuse.
In iOS, there is no one or the other, depending on what method to choose (layout in the code or in Interface builder). Yes, both of these problems are solvable, but you have to write a decent amount of code.
React Native does not have this problem.
In Android, by the way, it does not exist either.
But Android experts will appreciate the way to transfer parameters from external components to internal components directly in the markup.
Base View here is an analogue of LinearLayout (android) and UIStackView (iOS) with an admixture of constraints at the same time. Quite a simple way (compared to konstrayntami) positioning elements.
UIViewController and Activity
In React Native there is neither one nor the other.
Of course they are under the hood. Directly interact with them will not work. Yes, it is not necessary.
The life cycle of all React Native components is completely different from iOS and android, it is difficult to draw any parallels. If you focus on differences from native systems, then:
- UI elements themselves change state / view when input parameters change;
- on android there is no need to juggle onSaveInstantState . React Native does all this for us;
- On iOS, there are no methods that directly explicitly report when the application screens appear / hide.
Build time / Live Reload / Hot Reload
Greater speed is achieved through incremental build - only modified modules are reassembled, not the whole bundle.
All changes in the JS code are visible immediately visible in the simulator. Greatly accelerates development!
Lack of native functionality in JS
In the JS-part React Native out of the box is not all that is available.
You can write the native part on both platforms, make a JS wrapper and call it as the rest of the code. There is nothing complicated.
There are a large number of ready-made modules written by third-party developers.
All modules are connected via npm (analog CocoaPods for iOS and Gradle for android), in which there is a native code with the necessary functionality.
Universal and deep links
The functionality is implemented by Facebook.
It works well and consistently.
Handling third-party content
As a special case of the previous paragraph.
The biggest problem on android is to handle an Intent other than diplink in the application.
Depends, of course, on Intent'a and what needs to be done when it is received.
On this topic, you can write a separate article. The starting point is to add the createReactActivityDelegate method to the MainActivity.
Performance
It's pretty easy to get 60 FPS when scrolling through long lists with complex cells.
The performance of everything else (for example - clicking on a button, printing text in the field) below. Noticeable with an animated change of state for a large number of elements. This can be easily dealt with. A good section in the documentation is Using Native Driver for Animated .
And from the box it is impossible to get normal control of gestures and their linking with animation.
Instability
Often the project simply stops being built, for example after:
- kernel updates React Native (including when updating the minor version);
- updates of npm-modules;
- Xcode updates;
- CocoaPods updates (there are generally permanent problems with this);
- just. Yes, it happens too.
Fortunately, most of these problems are fixed rather quickly. You can add a script that cleans all caches everywhere, and run it when something goes wrong. Helps to solve 98% of strange problems that have arisen from nowhere. With the exception of CocoaPods, everything is sad.
Instability of third-party dependencies
The biggest problem on iOS was and is the widespread desire of npm modules to use method swizzling .
A lot of native modules are connected by binary. Understanding that multiple independent modules swapping the same method is not so simple.
Assembly takes place in several stages and at each of them something can go wrong.
Instability when updating third-party dependencies
Some npm-modules depend on other npm-modules and so on. If two modules are tied to different versions of the third module, then we immediately get a warning when installing, at best. In the worst case, there is no warning, but nothing works.
A similar problem if npm modules rely on native Android modules with different versions.
After cleaning the cache, new versions can be quietly loaded. It seems that he did nothing, but he stopped working.
Unit and UI testing
A very easy testing mechanism through the Jest library, bundled with React Native. Convenient analysis of test coverage - shows which lines in the tested function were not called once.
There are libraries for UI testing. So far, in fact, did not have to use.
Conclusion
After 13 months of working with React Native, I can say with confidence:
- It is suitable for most applications in which you just need to get a list from the server, show the list, show a detailed view of the list item, send changes to the server;
- all of the above is achieved with less code;
- now this is my “default” choice for new projects that are being addressed to me, because see the previous paragraph;
- not suitable for projects that go abroad “sent a request - received an answer”, a few examples: photo editor, player, work with Bluetooth, AI, ML, social. network, instant messenger;
- advanced projects can be done on React Native, but you still have to write a lot of native code, so there is no point;
- React Native has come and will not go anywhere, this must be considered;
- The demand for native mobile developers will slightly decrease, the influx of new native mobile developers will decrease much more. Why? see below;
- a person usually follows the simplest path, and there is no need to try if 95% of applications can be made by spending 20% of the effort (compared to native development) to study;
- as a consequence of the previous three points: the gap between supply and demand of native mobile developers will become even greater. Those who really cannot do without them will find it even harder to find them. This is sad.
The final word is for someone who immediately began writing on React Native and for some reason decided to read this article, even to the very end.
If you think that you figured out the topic and you are good at it, then please, please try yourself as a native developer.