How to Refactor your React Native App

Surely, there are certain rules when it comes to refactoring your React Native code. First of all, it’s best to do refactoring gradually — modifying big chunks of the code at once might lead to even higher code complexity. Plus, the developer working on refactoring should be well-acquainted with the code and, ideally, have worked on it previously.

However, with the right approach and enough patience, it’s likely to make your code more understandable and ease the app’s maintenance in the future.

In this article, we’ll talk about the most widespread refactoring use cases and show you exact ways how you can do it. Additionally, we’ll give you a couple of hacks that Stormotion developers use to make refactoring easier and share some real-life cases from our experience. So, if you feel like your React Native app could use a little polish or you’d like to be set & ready for refactoring in the future — welcome! 🚀

Everything mentioned in the article is applicable to such JS/TS concepts as functions, components, hooks, and classes. So, as not to confuse you, we’ll be using the word “unit” to define all of them.

✅ Top Refactoring Use Cases & Handling Examples

In this section, we’ll talk about cases when refactoring is most likely applicable and give you exact examples of how you can improve the code in such situations.

Code Duplication

There are two types of code duplications: let’s call them visible and invisible. Visible ones are practically code blocks or line repetitions that recur in different parts of the code. They’re pretty easy to deal with since you can spot them right away.

Invisible ones are the real problem. You can find them only by getting deep into the code’s structure and spending quite a while examining it. They imply having several units that lead to the same result (are responsible for the same functions) but are written differently.

Both types can be harmful in several ways:

• extra code parts make the code less understandable. Duplications don’t bring any new information yet increase the size of the codebase, which makes it more time-consuming and challenging to read the code.
• it creates additional technical debt.
• in case you find an issue in a code and have duplications of it, you’ll need to fix the same problem in every single one of them.

We actually have an article on covering the technical debt. So, in case you’d like to learn more about the topic, feel free to follow the link:

The first needed parameter would be the function that is to be memoized, the second one is the dependencies array. In case one dependency is changed, the React hook will automatically recompute the whole function.

But surely, don’t forget about keeping a balance. Optimizing itself requires resources as well, thus, it can be excessive in some cases. For a deeper understanding, we highly recommend taking a quick look at this article — it has a lot of practical examples.

👨‍💻 Expert Hacks: How to Make Refactoring Easier

As we also do refactoring at Stormotion, our developers have found several ways how you can make it less of a challenge. In this section, we’ll share them with you.

Perform Refactoring in a Separate Branch

It might be a great idea to create a separate feature branch to perform refactoring (especially relevant for large-scale refactoring). It can be feature/refactoring branch, for example. Once the feature is done, you can simply merge this separate branch into the main one.

The concept is pretty simple — you set up an automated refactoring feature within the software and tell the software how/how often it should be performed. It can be removing duplicate codes, fixing issues with headers, etc.

🚀 Our Expertise: Numina & FitTracks

As a software development company, Stormotion surely has a lot to do with refactoring. And in this section, we’ll share 2 of the most representative cases from our experience.

Numina

Numina is an app that helps with developing leadership skills. It includes a bunch of short lessons/courses and is suitable for both individual growth and team building.

This React Native project was developed using the Expo tool. The key refactoring goals were:

• Updating all dependencies of the project, including Expo (version 34 to 39) and react-navigation (version 3 to 5).
• Bug fixing. Once we updated the dependencies, we had to work on some issues related to video/audio playback and compression.

While working on this project, we’ve felt the importance of not changing the code too much since it could damage the business logic. To make it as careful as possible, we’ve performed a thorough refactoring planning so as to break the process into small steps and not do anything excessive.

💡 Takeaways

Even though refactoring is a challenging process, it’s worth it in most cases. It can help you reduce costs, prevent issues, deliver future updates faster, and generally have a better performance of your app with less resource consumption.

Let’s briefly sum up what we’ve talked about in this article:

1. The most popular cases when you might need to perform refactoring is removing duplicate codes or simplifying some parts of it that are too bulky. Additionally, you might perform code optimization by reducing the rerendering frequency or excessive computational calculations.
2. To make the refactoring less complicated, try to do it in a separate branch, stick to the same code style while doing it, and take a look at available/suitable refactoring automation opportunities. In case you’re not doing it on your own, we’d recommend discussing its relevance with your development team.
3. Read as many refactoring case studies as you can find. Surely, every single case is individual. However, learning from others’ mistakes or getting inspiration from successful refactoring cases might save you a lot of time in the long run.

In case you have questions left, need help with refactoring your solution, or want to contact us for any other reason — feel free to do it anytime!