📈 Elevating Our Business: The Journey of Migrating a Bulky React App 💼

Introduction 👋

If you are a web developer, you know the drill. You want to make your web app faster, smoother, and more awesome. But how do you do that? How do you optimize your web app for better performance and user experience? Well, buckle up, because I’m going to tell you how we migrated tooling of our legacy react app. I will also share with you how we tackled some of the common challenges that React developers face, such as large bundle size, unused dependencies, and compatibility issues.

Background ⏳

I joined as a UI lead in a new team @ Syngenta. We had one old react app. It was hard to maintain as a zoo. It had some noticeable performance issues and frequently displayed signs of erratic behavior. But, like a stubborn mule, it managed to handle our business requirements for a few years.

We had two options to choose from:
1) Do nothing OR 2) Roll up our sleeves and fix it.

Not doing anything was never our preferred choice, and so we chose the second option after estimating scope of efforts and time in hand as quality of work is more important than quantity.

Before I begin to share our journey of migrating to a bulky React app, let us take a moment to acknowledge the popular challenges that many React developers face at some point in their career.

Common Challenges 🤯

Large bundle size: React apps can become very bulky and slow to load if you have many dependencies or code that is not used or optimized.

Unused and misplaced dependencies: It’s important to analyze each dependency and remove it if it’s unused. This can bloat your bundle size.

Compatibility issues: React apps may not work well on older browsers, so you need to find ways to make your app compatible with different browsers and devices.

Breaking changes: Latest versions of libraries may introduce breaking changes that require you to update your code.

Deprecated features: Features that were available in older versions of React or component libraries may be deprecated in newer versions, so you need to find alternatives or workarounds.

As Steve Jobs said, “Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple.”

If that inspired you, keep reading..

Off we go 🏇

It wasn’t all rainbows and unicorns.

We faced a major challenge: our build system only supported Linux, but we used Windows. Awesome! This was never seen as an issue earlier because everyone was a flashy Macintosh owner, unlike us mere mortals. We hit a wall on day one but tackled it head-on like trying to catch a train on fire. It only took us 3 days to achieve platform independence. Excited, we went ahead.

Solution :- We used NPM libraries such as “cross-env”, “rimraf”, modified our Dockerfile and removed hard-coded references to bash scripts in “package.json” file.

Here are some modifications made to the code :

 
"build": "cross-env NODE_ENV=local parcel build ./src/public/index.html --public-url '/'" 

"prod": "cross-env NODE_ENV=production parcel build ./src/public/index.html --public-url '/'" 

...

"rmdist": "rimraf dist", 

"rm_node": "rimraf node_modules", 

Oh, how beautiful. Next came the daunting task of upgrading our Parcel bundler. It was like walking through a minefield. We had to learn and get used to many other minor changes and better ways of doing things that the latest version gave us with respect to memory and performance optimization. It was not a simple task, full of situations which wanted to push a boulder up a hill.

Solution: — Upgrade Parcel version and associated plugins. Followed steps given in Migration (parceljs.org), and Production (parceljs.org)

Here are some modifications made to the code :

.gitignore file

# Before 
.cache 
 
# After 
.parcel-cache 

# Before 
.parcelrc.js file


# After 
# .parcelrc file
  {
  "extends": ["@parcel/config-default"],
  "compressors": {
    "*.{js}": [
      "@parcel/compressor-gzip",
      "@parcel/compressor-brotli"
    ]
  }
}

We executed the below command to add GZIP and BROTLI compression plugins inorder to improve build and runtime performance.

yarn add @parcel/compressor-gzip @parcel/compressor-brotli --dev

Using type="module" in a <script> tag lets you use JavaScript modules, organize your code, and can speed up page loading by deferring script execution.

<!-- FROM -->
<head> 
<script src="abc.js"></script> 
</head> 


<!-- TO -->
<head> 
<script type="module" src="abc.js"></script> 
</head> 

We wanted to understand the size and composition of our bundles frequently so we could optimize them for faster loading. The following command in package.json file helped us achieve that:

"analyze": "parcel build src/index.html --reporter @parcel/reporter-bundle-analyzer", 

To upgrade NodeJS, we used the “volta” tool that let us switch between different NodeJS versions.

Here are some commands we executed :

volta install node@18 
volta pin node@18 
volta run --node 18 npm run test 

The ncu -u command was experimented to bump the dependencies in the package.json file to their latest versions. However, the updates were not implemented due to the presence of numerous breaking changes.

This is just a quick look at some of the code tweaks we did to get our app in line with what our clients are expecting. Pretty cool, right? 😎

Top Gains 🏆

Faster and easier development of new features

Latest features and options with improved flexibility

Easier testing and debugging

Higher code quality and maintainability

More learning opportunities, challenges, fun and satisfaction!

This journey was filled with valuable lessons and insights. They can act as your personal compass if you embark on a similar journey in the future.

Learnings 📚

Go and read the new bundler’s documentation, changelog, and breaking change list before you begin. You may find a lot of things in advance.

Have a Plan B if things do not go as expected. As they say, “A stitch in time saves nine”.

Check the new bundler’s compatibility with your app’s dependencies and configuration. In short, Upgrade incrementally.

Get your performance tests ready.

Backup your code before you begin.

Follow the migration guide or instructions from the bundler’s developer or community.

Look out for useful tips, tricks, tutorials, or best practices on websites like FreeCodeCamp, LogRocket or Medium.

My thoughts 💭

This journey was like camping in the Amazons! We learned how to juggle trade-offs, and even though it was tough, it was also super fun to learn new stuff and level up my skills.

We got a ton done in a short amount of time, and it was brilliant. We had a bunch of ideas for making the existing app even better, but we would definitely revisit them in the future.

The whole experience was priceless, and I know the stuff we learned will come in handy in the future.