React Native is still a hot topic at the company. After spending some time with it, many of us have some thoughts and I think there is still a lot to say about it so I would like to share some of my observations and feelings.
This post is going to be extremely subjective so please don’t treat it as the only truth. Actually, there are as many different opinions on RN as there are people who have worked with it… or even more :)
Or maybe I should say: „the lack of it”? It’s not like there is completely no documentation at all. It’s just poor, incomplete and therefore not particularly useful from time to time.
A quick example: try to understand the
Even if you do understand the
KeyboardAvoidingView, let me add that it works differently on Android and iOS, so after a few hours you either end up with some weird solution (like putting all your views inside another view, which experimentally proven to be helpful, but it still needs some tweaking) or you give up, saying: „let’s hope the user will be smart enough to hide the keyboard and find that login button at the bottom of the screen”.
Fun fact: at some point I’ve found out that the keyboard avoiding behavior works well until I open the next screen, and another, and finally go back to the first one — then it doesn’t. Magic trick!
(Now I start to think the keyboard avoiding feature deserves it’s own blog post…)
I am a great fan of open source projects, but RN is a bit disappointing in this aspect, especially considering that it’s maintained by Facebook. Unfortunately, the maintainers can’t keep up with a huge number of reported issues and pull requests. They even admit that by posting automated comments like this:
React Native, as you’ve probably heard, is getting really popular and truth is we’re getting a bit overwhelmed by the activity surrounding it. There are just too many issues for us to manage properly.
And it’s quite understandable, but did you know about it before reading this post? It’s easy to get hyped and then regret it.
Another thing I don’t like about it is the way the GitHub issues are managed. Many of them are being closed and moved to another issue tracker (but not always). I know it may be easier to manage this number of issues using some better tool than GitHub, but hey — why do you close them? A few times I have heard something like „RN has only 500 open issues on GitHub, it must be quite stable considering it’s size”. Nope. (example 1, example 2) And often you don’t even know if the issue was fixed or not — it’s not mentioned anywhere (neither GitHub nor the ProductPains).
Eliasz has already mentioned some of our debugging experience in his post, but let me put my two cents in.
Sharing the code for both Android and iOS is just awesome. No more questions for missing translations, complex algorithms, color themes, fonts etc. What a relief!
If I could take just one RN feature to a deserted island of native development, it would be the layouting. Now, working on a non-RN project again, I must admit I miss it. It’s probably the most pleasurable code-XML mixture I have ever seen.
Storybook is a great tool that helps you design and develop UI components without running the app. From Android developer’s perspective it’s even better than the layout preview mode in Android Studio, because with Storybook you can also easily populate your components with some real data and see how it looks. At some point I was using two Android emulators and one iOS simulator simultaneously, testing all my code changes in the UI almost immediately thanks to the Storybook.
I know that after reading this post it might look like there are so many terrible problems with RN that you should stay away of it at all cost, but I don’t really mean it. I just like to complain a lot :)
Now you are much better prepared if you decide to give it a try and, believe me, it’s worth it. Even if you don’t decide to stay with it much longer, the experience you are going to gain is priceless.
I would love to see RN mature to the point where you don’t have to struggle with it so much.
(and I wish it were using Kotlin instead of JS/TS…)
This article is crossposted with author's personal blog.