My thoughts on using React Native
I’ve used RN the last couple of months and I’d like to share in this post, what, in my opinion, is very positive about RN, which things need to be improved, and in which scenarios is a good technology to consider. Let’s tart with the positive points.
The fact that you don’t have to compile your code makes TDD possible. You can just save your changes and get instant results. There are a lot of plugins for the IDEs that you can use to get the results on the UI. For example, [this plugin], shows you a dot next to your test, with a green or red color, depending on the result of the test. Moreover, you’ll find different testing approaches and tools so you can find the one that suits your needs. For example, you can use Jest (also from Facebook) that provides a cool snapshot testing feature.
Honestly, RN is very bad at this. I’ve gone through this nightmare in different projects, and it’s not very straightforward. RN offers a [command line tool] that you can execute and tries to migrate your project. However, the tool doesn’t work as well as expected, and sometimes you might even end up [solving conflicts manually]. I’ve seen developers solving this problem by generating another RN project using the last version of the framework, and then copying and pasting files and config from the previous project. This is really bad! Upgrading sometimes implies changes in the native setup (Android and Xcode projects), and if you tweaked it a lot, RN might break/reset your project during the upgrading process. It’s not something funny that you’d like to go through!
On the web ecosystem, frameworks have tried to abstract developers from accessing the DOM directly, and have allowed them to focus on defining how the layout looks like. From the developer’s point of view, working on a website using these frameworks is nicer, and faster, and from the user’s one, it might be the same, or better (it all depends on how you architect your website). Nevertheless, if you apply the same principle on mobile, the experience from the user might not be the same as if the app was built entirely with native code. Why? To ensure the experience using the app is the best, iOS and Android frameworks provide optimized components that are designed to have a good performance and responsiveness. RN components are designed to be cross-platform, and easy to use for developers, but when they get rendered, they sometimes don’t have the expected native behavior. You need to tweak the components and their lifecycle to get closer to the native experience.
Animations have always been a challenge for RN. They usually rely on delivering/observing a stream of events (think about a parallax effect in a scroll view). Since that stream is sent through a single-threaded bridge between React and native, other events might get delayed, and it ends up affecting the responsiveness of the app. One of the approaches RN it trying out to solve this problem is coming up with a declarative manner for defining your animations. Instead of having a stream, the specification of the animation would be sent to native at the beginning, and the rest would be performed on the native side. While this works if the animations are simple, you might find it limiting if you want to build up something more custom. In that case, my recommendation is that you build the component natively, and handle the animations from there.
This is my personal opinion based on my experience, and it might change soon since the framework is evolving at a really good pace. If I had to choose between using RN or not, I’d keep the things in the list below in mind:
- If the component that you are building is very heavy regarding animations, I’d build it in native. Although they are trying to improve the animation APIs, by using them, you might compromise the responsiveness of your app.
- Having a person with the experience with the native tools is a good thing to have.
Gradlemight not be that straightforward for a web developer. Although you might not need any help from then 90% of your time, as soon as you touch something in the config, you might break the whole setup easily. That person could help you analyze and understand the errors that you might get from the build system.
- RN is great for prototyping; I’d definitively use it for it since you can try things pretty quickly and use real APIs that developers will use when they build the final product.
- There isn’t a clear navigation pattern established yet so I wouldn’t define the navigation from RN. It allows you to combine views that are entirely native and views that are RN.
- If the code base is purely native, and you plan to build a new feature in RN because you want to reuse it with other platforms, I’d try that feature to be as atomic as possible. You should be able to think of the feature as an input-output box, minimizing dependencies with the app.
Do you have experience working with RN? I’d like to hear about the things that you liked and disliked from the framework, and what are your wishes for future versions. Reach out to me or leave a comment below. Thanks for reading and I hope you liked the post.