<img src="https://ws.zoominfo.com/pixel/UFH1H1ydGvMVOr12BP8x" width="1" height="1" style="display: none;">
ic_close

Get your demo today

Now you can control, manage, and save money on the SaaS being used by your company.


Let us show you what Torii can do for you.

How We Migrated Our Codebase To React Hooks

Ziv Erlichson | Mar 31, 2021 6:50:44 AM

How we migrated our codebase to React Hooks2Introduction

During my interview process, I was told Torii uses React for its web application, but it wasn't until I joined that I saw that the codebase, created somewhere in 2017, was built from classes for stateful components and functions for stateless components.

Having worked with Hooks in my previous workplace, I figured that migrating the code to Hooks would be beneficial for the company. But being the new kid on the block, I didn't want to introduce such major changes before I got the feedback and support from the team.

Read on to see what I did to get the buy-in to make these changes less than a month after I joined Torii, what the outcomes were and what challenges we encountered during the process.

How I Got My Team To Join Forces

I first raised the topic during a conversation with my manager. I wanted to get his first approval and ensure there was a place for such a change. After discussing the pros and cons, we decided to move forward and raise it at our team meeting to get the interest and approval of the rest of the team.

I created a short presentation to convey the topic in the most professional and interesting way.

To make the transformation as smooth and simple as possible, we divided the process into two parts:

  1. We ran a short session about hooks: overview, advantages, use cases, and examples
  2. We started converting the components, following these guidelines:
    • We began with the simplest components in the system - this made the changes easy to implement and simple to read and understand
    • Each converted component was committed separately - this also enabled the addition of rich descriptions of the changes to make it easier to understand.

Why Change Something That Is Working

A wise man once said: "don't fix it if it ain't broken". While the saying is true in many cases, in our case, migrating to Hooks has had many positive outcomes, some over the short-term and others over the longer-term:

  1. Simplifying our codebase - classes are a facade, and they simply wrap JS functions to make it easier for developers to work with. Hooks, on the other hand, are simply functions and they are, therefore, easier to understand, both for developers and the compiler. In many cases, hooks also allow us to shorten our code and divide our components' logic better.
  2. Keeping ourselves updated - over the years, Hooks has become the standard to developing React applications. Many new open-source packages for hooks have been created and many existing packages have migrated to hooks, while sometimes introducing breaking changes and deprecating older versions.
  3. In addition to these internal advantages, we knew that working with the latest features of the framework would be more appealing to potential candidates and new hires.

Migration Challenges

Prior to any change, big or small, it is always advisable to take into consideration both sides of the coin, to understand why we should or shouldn't make the change. Alongside the benefits of the change, one must think of what might go wrong and what the effect of this change might be, both internally and externally.

For us, while the advantages, as described above, were clear and convincing, there were some drawbacks which we had to take into consideration before beginning the migration:

    1. Solved performance issues could re-appear - some of the issues we had encountered along the way were solved by using class-specific solutions such as Higher Order Components, should Component Update, and Pure-Components.
    2. Unintended changes in behavior - similar to performance issues, migrating to Hooks could also lead to unintended changes in component behavior. We had to make sure we maintained the same design, functionality and behavior of each component we migrated.
    3. Developers who prefer classes - to make this change, we needed to have everyone on-board, even those who preferred classes over hooks. There are many developers who are more comfortable and experienced with classes, and the learning curve, as small as it may be, must be considered.

Closing notes

If you want to drive change in your company, explore the subject, educate the team, encourage them to join you, and last but not least - be open and prepared for feedback, criticism, and objections.

We are still in the process of change and there is a long way to go, but more and more components are being converted, and the advantages are already apparent.

And most importantly, as Dan Abramov promised when he first introduced Hooks - the components coexist, and the changes are transparent to our customers.

 

Migration, React, JavaScript, Hooks, Fullstack

Author: Ziv Erlichson

Ziv is a software developer at Torii. Ziv is a fan of Albert Einstein, Elon Musk, and code, not particularly in this order. In his free time he enjoys sports (Go Liverpool!), traveling, and spending time with his family, and he believes that appreciation and gratitude are what drives people to success.
Find me on: