Pitfalls to Avoid While Migrating to a New Framework
Every team faces technology debt at some time or other. Technology’s rate of change has grown like never before, especially when it comes to Fintech. Day to day, new startups that use more trending and efficient technology emerge. Providing a better experience and following the market demands teams work at their hardest, thus enlarging risks and consuming more resources. That’s why I think migration over to a new framework is a conundrum: systems with a vast majority of dependencies and complex structure would benefit the migration the most.
Below I have outlined a basic roadmap to give attention to each stage of upgrading AngularJS to Angular as an example of how to avoid the pitfalls such a migration may bring.
1. Style Guide requirements
What has easily worked for AngularJS is incompatible with the Angular Style Guide. The first pitfall is the inability to store several entities in one file in Angular. The patterns and practices outlined in this guide help align an AngularJS app more closely with Angular so that it can be migrated more seamlessly.
Here’s an example of an Angular Style Guide rule (more examples are here):
Style 01-01Do define one thing, such as a service or component, per file. Consider limiting files to 400 lines of code. Why? One component per file makes it far easier to read, maintain, and avoid collisions with teams in source control. Why? One component per file avoids hidden bugs that often arise when combining components in a file where they may share variables, create unwanted closures, or unwanted coupling with dependencies. Why? A single component can be the default export for its file which facilitates lazy loading with the router. |
To comply with the rule, you should move each controller code block to the newly created dedicated file and rebuild the application. Find code samples for implementing the stage in our whitepaper.
2. Make room for webpack
To upgrade to Angular, you’ll need to use webpack. However, first, it will be necessary to delete previously used Gulp, Grunt, and other module loaders. At this stage, it’s vital to make sure you don’t miss anything while cleaning up your code. This would require substantial testing from QAs, and it’s your responsibility to clean up the code so that regression is needed as rare as possible. If you’re new to webpack, follow the link to learn more.
