How often have you needed to modernize a legacy frontend application and re-build them using a more modern technology/framework like React/Angular etc.?
At my current job, I have to migrate a JQuery dashboard to React. I was wondering what other people's experience has been in this regard.
What was the most painful part of migrating an existing app to React/Angular?
What were some of the pitfalls that I should look out for?
If you had to do it again, what would you do differently?
I have retreaded the front-end of line-by-line I/O to full-screen on mainframes. I've transitioned from green-phosphor only displays to 8 color (16, if you count light and dark versions of each color). I've rewritten DOS programs to use Windows API calls and, well,...windows. I've replaced mainframe and distributed front-ends with web pages. I've redone websites to replace, revise, and add new options per changes to the business needs. Finally, I generally think that few front-ends are ever truly finished. Apps, especially good ones, evolve over time. Any really good app - and its UI - offers the potential to refine existing features, accept the addition of new features, or retire aspects the business has outgrown. Changes to the model layer almost always demand reflection in the user interface.
So, with that having been said, what sagely wisdom have I distilled?
Be sure your use-cases are accurate AND enforce flexible transitions.
Use ANY opportunity to evolve the UI as an "excuse" to fix other stuff - refactor, refactor, refactor.
Involve your users early and often - they know WAY more about their workflows than you do.
Not all that originally sagely coming from me, right? Pretty much what most us have been taught for the last thirty years by various masters of our craft. I will say that it has the virtue for me of having been stamped on my hide by live experience - I am NOT conjecturing - I know.
As a matter of fact we did go through a major refactor of whole App from being jQuery powered to WebComponents powered.
Painful Parts, Pitfalls etc are:
Framework
Sit back, try, discuss, experiment with Libraries and Frameworks. The go ahead with Refactor; you don't wanna look back and say we must have chosen
yyzzinstead ofxxzz.DataStructure
The AJAX requests needed change in Data Structure of Response and hence increased the time needed to complete the refactor on time.
OnGoing Fixes
While you are at refactor, there is still work needed to be done. Work like Fixes, small feature improvements, legal requirements etc and that will push it further.
Best way is to keep one person in team ready to pick up these emergency tasks.
Expectations
As the expectations keep increasing by time; pressure to finish also keeps increasing.
Best way is to plan the gradual Refactor; all at once Refactor can go wrong in many ways. Refactor -> Release; Refactor -> Release; and keep doing this until you have whole app refactored.
Design
Don't try to make Design changes; this way you keep at-least one stakeholder out of the loop; Design Team
Tooling
Think from beginning about the tools needed to be used; configurations etc. Discuss and Agree on App Structure and patterns so that everyone in team knows about those
UI
While we were refactoring, we were coding components in parallel and because of that; some styles groups are repeated very frequently like Buttons; Grid; Typography etc.
Better to do a common styling first and then everyone use it.
API
Component API; naming; variable naming; function naming; structural arrangement etc is pain in the ass when everyone goes by their way
While we were refactoring; one of the team member did so with Vim and others with Atom/VSCode. And man we always end up fixing the spaces and code beauty complains from Editor.
Use editorconfig and linting and enforce it.
Testing
I am pretty sure that as you will start the new refactor; testing will come up. Spend some time; set it up properly and enforce it. Once ignored, always ignored.
Packages
It is true that these npm package for literally everything and even battle tested. But before including them, make sure that you really really need them and will save you a looot of effort.
Like a Basic Calendar or Complex; AutoComplete as package or your code yourself etc.
Cleanup
Don't leave the old code behind; it takes forever to cleanup once you are done with refactor.
Documentation
You have chance to do it right, from beginning. As you make a refactor release; do the documentation of that refactor and while coding components, add a small readme file for the API and function of the component. Storybook is also an awesome way to document the components.
Assets
Settle with easy and fast way for asset inclusion. Assets like Fonts, Images, SVGs (inline or as file) etc.
If I were to do it again,
Above things are on top of mind. I will keep adding more things as I recall; as the refactor is now 1 year old ๐; probably I should think about another refactor ๐