Migrating from AngularJS: A Day at Our ReactJS Control Room

Writing about ReactJS at my organization makes me curious to look into the daily workings of our React.js team. I pressed the idea to some of my teammates with little skepticism, who got the validation from the team lead. The lead passed the request to the management and voila I received an invitation the next day.

Breaking Down the Agenda

The invitation was from Team Alpha or our go-to team for any sort of React development. The invitation email had all the details about the project and agenda of the day.

Team Alpha includes a number of React veterans, everyday web developers, and erstwhile AngularJS developers. Evidently, they are the first in line to adopt a project that has the word “AngularJS” and “migration” in the scope. Luckily, they had adopted a new project on the day. A team meeting was called and I was on the invitation list.

The blog is my attempt to showcase how we, at TOPS, approach technology migrations, particularly AngularJS to ReactJS migrations. It is the result of spending a day with the leading ReactJS development team at TOPS and many more following meetings. Before discussing the day, let me give you a brief about the project.

The Project: Origin and Broken Trust in AngularJS

When I say they adopted a new project, I did not mean ‘new’ in the strictest form. The project I am talking about was an AngularJS application. The same old story: Google is pulling the plug off AngularJS and businesses with interests in AngularJS are keenly looking for new home for their application.

The application we were supposed to migrate from AngularJS to ReactJS was a part of an enterprise suite. It was an employee-centric application and created 8 years ago. The employee portal was client’s first interest into AngularJS and JavaScript realm. The whole prospects of single page applications made the client excited while their management was already drawn to the hype. A little push from a consulting firm and they built an innovative web experience for their employees.

A Smooth and Focused Transition and a Funny Client Call

Application migrations often mean rewriting the entire application from scratch. At the meeting, nobody wanted to spend months rewriting the entire codebase in ReactJS. We had a fun argument with the client and somehow we convinced him otherwise. At TOPS, we have a strong client-centric culture and we didn’t want to slow down too much on our mission. Additionally, it is a high risk to rewrite everything about an app without testing the water.

It was decided each week Alpha Team would meet for a developer exchange meeting at a conference room, where they will share learnings, brainstorm ideas, but also take larger undertakings. We discussed and decided on the idea for the migration strategy and allocated a sub team of erstwhile AngularJS developers to develop and present the migration strategy.

Redefining the Migration Strategy: Technicalities and Logics

A frontend application is actually a set of HTML documents featuring an edifice of nested HTML elements. Likewise, modern web applications tend to feature an edifice of nested components. A streamlined replica of an application showing a list of comments from employees may look like that:

The analogous component tree looks like this:

After deciding the migration strategy, the rest of the day passed contemplating complexity replacing and rewriting this tree. This step got a little technical. I will try to explain in as approachable terms as possible but…

The main Application component is wired up with complex logic like routing. The routing is deeply integrated with the main components and a key piece of AngularJS. NavItem is friendlier. It displays a link, has some trivial logic like “am I ready” and displays anchor text.

The content part of our app contains sub tree showing a list of comments. The ComponentList is complex, as it is attached to the data layer and may retain state: what item is selected etc. The Comment is the easiest part of that tree. It essentially renders a Comment and handles user interaction. The Text component for example is responsible for rendering the text. That component will render in another technology without hiccups

Our conclusion was this that the more you advance down the component tree, the easier it becomes to swap components. For the remaining time, we established the guidelines and looked at elements for that migration strategy. Here are some of the highlights.

Key Guidelines to Migration

• What about new features?

We decided we will built new features in ReactJS & Redux.

• What about existing code?

If possible start to migrate leaf-first up to a whole component tree until you hit the routing module. If you touch old code/ components, estimate how much it would cost to rewrite it, if less than 30 minutes, rewrite, and else get a second opinion.

• What is the simplest way to migrate common UI components?

The rudimentary building blocks of a web app are standard, reusable UI components, like Drop downs, Buttons, Forms etc. They are essential to build new components with React.

Re-write generic UI components when you need them, and let other devs know that they now exist. Use that chance to improve the design/ UX.

Tags

• angularjs to react migration
• ReactJS