Managing A Long-Term Ticket: The Never Ending Apollo Upgrade
By: Eli Sadoff
Tags: Apollo Client, Typescript, Upgrade, Apollo, React

This upgrade necessarily had me touching large parts of the application. I took this opportunity to do two things. One of those was to familiarize myself with the large swathes of the front-end that I know exist but have not had a chance to work with previously. This project definitely led to me having a far better understanding of the front-end code for our project on the whole.

The other great opportunity I got from seeing and touching so much front-end code, was a side project of modernizing old-style react code. As Tatami/FlooringStores has been an active project for quite a bit now, its existence has spanned multiple paradigms for React. Especially when the application was first being built, class-style components were still quite hot.

Now, as we’re in late 2020, it seems like the move has been to go towards functional components. If there are any class-style components that I end up significantly touching, I also make an effort to convert those to functional components. These refactors have been one of the parts of this ticket that I have most enjoyed.

Lesson Three: Keeping Up To Date With Master

CC4 License, Merge Icon by Daniel Bruce

One of the major challenges I faced about three weeks into the project, was that I realized that I had not been keeping my branch up-to-date with master . This could have caused some big challenges when attempting to merge this whole upgrade in when it is eventually completed, had it not been addressed. The first time I merged in origin/master it was a pretty big mess. It took at least an hour, if not longer, to resolve all of the merge conflicts. After that tough lesson, I started merging in master much more frequently.

Any day where I am working on this ticket, I start that day with the following command git fetch && git merge origin/master . Keeping this branch up-to-date with master can be difficult at times, especially when there are components that have been touched by tickets that were also components that I converted to being a functional style component. Here is a contrived example to demonstrate what I’m talking about.

// Old style class component

Old Style Class Component

// My conversion to functional type

Functional Component

// Merge Conflict

Merge Conflict

This is a bit of a mess to resolve at times, especially for non-contrived, real world examples. Normally what I would do is take whatever methods are on the class and pull them outside to be top-level functions. With the more frequent merges from master , I have been able to catch these problems more quickly.

Conclusion

It’s very important to update your packages, but you might not want to do so at the very first opportunity. It might be worthwhile closing that dependabot PR, or at least putting it on hold for a bit if it’s a major version upgrade.

When you do get around to making that upgrade, use it as a chance to refactor. It really is a great way to get to either learn or re-familiarize yourself with the codebase and is an opportunity to modernize the codebase to current paradigms.

Furthermore, make sure that you keep your branch up to date with your master branch when doing the upgrade. Refactoring, while delightful, can be a bit of a double-edged sword if people are making changes to the components that you are refactoring. This can be dealt with more deftly if you regularly update with master and the changes are not too hard to manage in a merge conflict scenario.