#building react application

Prologue

AngularJS was a decent framework when you wanted to get an MVP live in no time although enforcing a robust architecture or securing great performance, AngularJS was never the first choice. The announcement of Angular as backward incompatible, complete rewrite of AngularJS killed the prospects of the framework and ruined the ecosystem around it. We realized AngularJS doesn’t deserve our time, efforts and money anymore; React was looking promising though.

Migrations: An Untold Story

Migrations are tricky whether it is moving from one home to another, one web browser to another or one development technology to another. Ideally, migrations should not happen but in our pursuit to move forward, we tend to abandon things that are not moving fast enough. Your home will start showing signs in 25 years and your car in five years. Internet Explorer went fine for more than two decades and is still in maintenance mode. Maintenance mode is a code in software world to indicate migration. It’s when you receive a notice from your landlord to empty the apartment in 60 days. You got to find yourself a new home sooner or later. We were in the same situation with an AngularJS application. The client had made his mind halfway towards migration. A little push and he was ready to React!

React for the Unreactive

React, Ember and Angular were the three options when we made our mind to make the migration. Angular was still in beta and not ready for production and, of course, “Fool me once, shame on you. Fool me twice, shame on me.”

Ember is a fine framework for most of the people. Ember touches spots where data-bindings, caching layers between various components and program flow gets a little sloppy. We did not want that to happen again. The whole concept where the entire UI is a clear tree and data flows top down from an immutable data store was a dream come true for us. I mean who doesn’t want their web applications to have this predictable architecture.

Developing applications in React is like setting up water pipeline in an apartment building. The water flows downwards from overhead tank down to the apartments below. Ask a plumber to develop a system of pipelines where water can move either ways. He won’t show up the next day—I am not a magician. Now you know why developers have embraced angularjs to react migration with open arms.

Fixing the Migration Approach

You are a proud Chevy owner and want to stick with a 1930 model as long as you will drive. However, one that you have is not up for your daily commute. You cannot do much because that is the only car that you have and you’re committed to it. You visited a renowned car modification expert in your neighborhood and he agrees to upgrade your car with a fresh coat of paint and 21st century mechanical and electric parts while you can still take it on a drive every evening.

If you’re a mechanic with unlimited budget, then creating a replica is less risky since the client is a little paranoid about his car and may freak out if it stops working during his daily drives.

In real world scenarios, this is how you approach migrations, automobiles or web technologies. This was our plan until… We will build an application clone in React and replace it with the AngularJS application one day. This is how migrations are done or is there another way? If I tell you that you can keep riding your car as you were and I will replace one car component every day until you have a new car. Sounds ridiculous? I thought so too then I realized this makes more sense in the context of software engineering than automobile engineering. A few “Google searches” later, we were fixated on this gradual approach.

Of course, many more factors influenced our choice. AngularJS was an incredible tool to setup MVPs and most of the applications were in a perpetual development cycle. Our scrum-masters decimated the idea of a rewrite. We had to integrate six features into the application in the next six months. A parallel, non-gradual approach meant we had to code the exact, to-be-integrated features in React as well as, god forbid, AngularJS. Some of the features we were adding were beyond the scope of AngularJS or were too much work. We could code the same feature in React in a matter of weeks. React is perfect ;).

Prerequisites

The application was still in AngularJS 1.2 as we were more interested in a migration than upgradation. The attempts to get rid of AngularJS finally and the legacy code was not of much help. In fact, the legacy code made the simple upgradation to AngularJS 1.5 a headache.

You will be shocked to learn we were hardcoded to Bower & Gulp. I repeat Gulp and Bower. You reach a stage in AngularJS development that you start improvising to survive. We reached that stage while developing the app a long time ago and after that, it was all playing with fire. We did not made the upgrade to npm and Webpack because it might break the entire application and we have to revert to the earlier version eventually. Now we have to make the upgrade one last time and we would do it with a smiling face.

AngularJS to React Migration – Key Points

The first thing you will notice while migrating AngularJS application to ReactJS is Components. Components are the building blocks of ReactJS; they are everywhere. AngularJS has directives and they are similar. You could switch the view layer from Angular style templates to React style components and things should turn out fine in most cases as long as you’re using one of those style guides, stick to yours and do not improvise. This is neither AngularJS nor will not turn out to be. You got to start on a solid foundation for your application. Converting Angular directives to React Components was facilitated by a JS library react2angular.

While the 3rd party library made the conversion approachable. We still had to pass them to Redux store. Yes, React + Redux is the industry standard when building React application. When building a new React application, you wrap the root components into Provider. In our approach, where we essentially adding new features in React to an AngularJS application, we had no options but to manually wrap each component with a provider. We were literally copy-pasting code, component after components although ng-redux made the job a little easier.

After a couple of months into making the essential parts work, we were on the last part—setting up routing paths for the newly development parts of the application in React. We wanted to be ready for production as soon as possible. To make things a little more faster and efficient, we wrapped the React component in an AngularJS component and routed it to an inline-template that employs the AngularJS component. react2angular was the reason we could complete the project faster and before the client expected.

Epilogue

When your approach is gradual migration, things get a little complicated. Of course, changing engine in a moving car is more difficult than in one parked in the garage. On top of that, you have to add new features as well replace the existing ones at the same time. Of course, this saves you from rewriting the same code in two different technologies. Nevertheless, making changes in the codebase of a live application is not very different from playing with fire. Gradual approach is indeed not the ideal way to face the migration.

A parallel rewrite makes more sense from both development and business point of view. It is more of a luxury and necessity. As I said technology migrations are not straightforward, sometimes to make things work and make business sense, you have to pick the unconventional way.