DEV Community


Discussion on: What're your strategies to upgrade a React app that's in production?

glebirovich profile image
Gleb Irovich

Hey Ahmed, congrats with your new position! Could you elaborate on the end goal you want to achieve. What do you mean by “upgrading React”? Upgrading a library? Unifying application codebase?

akaahmedkamal profile image
Ahmed Kamal Author • Edited

Hi Gleb, what I'm thinking of is this:

  • the codebase should be migrated from JS to TS.
  • the codebase should be covered by unit tests.
  • we should drop the unused libs/code and upgrade the outdated ones.
  • and finally, we should have some sort of "paradigm" to follow to make our lives easier as a team.

So, my questions are;
Am I concerned about the right things or I'm just overreacting to a new codebase?
Are my thoughts above valid?
and if so, How to achieve them?

Note: by "How to achieve them?" I mean what're the techniques to follow to apply these changes while working on fixing bugs, adding new features at the same time since the app is already in production.

The main idea of this post is to brainstorm with the community on how different devs deal with this kind of situation if that makes sense!

glebirovich profile image
Gleb Irovich

Hey Ahmed,

I think you are concerned about the right stuff. From my experience migration to a newer stack is rather a marathon than a sprint. So prepare yourself for the long run. Let's skip all the steps where you have to justify your changes and assume, that you got a green light. Here is some thought I have.
-> Migration to typescript can be relatively gentle. You don't have to make your app typed overnight. If you have a custom webpack, introduce typescript and allow js. Alternatively, convert all the files to ts extensions, but keep typescript flags loose. Migrate pieces of code whenever you touch them, slowly your codebase will move to the new rails.
-> Testing is always great to have, however, usually it's rather a cultural problem than technical. Your team must agree to write more tests (if they currently don't) and you should decide on the guidelines. When do you use unit / components / e2e tests? What technologies / libs to use?
Making testing part of the DoD (definition of done) is probably the most challenging part, because, for some reasons on the frontend tests are often being taken not serious enough.
-> updating libs is a nice idea, but it requires some planning, especially if some libs must be replaced and code refactored.
-> to decide on the guidelines we are currently using a weekly web tech exchange. If anyone from the team has to come up with some opinionated solutions, he simply adds it to the "inbox" and we discuss it. It helps to keep discussions very close to the use-case. Decisions are written down in and serve as a reference should anyone have the same question. Some guidelines can be also enforced with eslint rules.

I think you are on the right track. Have a plan and approach migration in smaller steps. Migration is always a stress for a team since people don't like changes, so communicate well and make sure you are aligned with your colleagues.
Good luck =)