Well, let’s lay down some facts. The Angular team has been on the forefront of this innovation. They have been one of the pioneers in providing the framework to build large scale applications. It now embraces the move to ES6 and TypeScript, and it’s here to stay.
But the fear and concern are still understandable. Adopting and upgrading to Angular 2 can be a big undertaking. Specially if you are responsible for an entire codebase.
There are so many issues that can pop up when switching to Angular 2 in a production environment. So the question we need to ask ourselves is –
“Is upgrading to Angular 2 worth it?”
Why Consider Upgrading to Angular 2?
The Angular team would not waste time rewriting an already great framework, if it didn’t come with some serious improvements.
Angular 2 adds so much value in terms of the performance and the development process.
For starters, Angular 2 runs much faster on mobile environments – the code base has been stripped of unnecessary features. Everything from view caching to template pre-compilation and reuse is aimed at reducing the pressure on memory and the VM.
Your IDE can now detect bugs and errors much faster thanks to the new and powerful templating features introduced in Angular 2. This equates to spending lesser time discovering bugs during run time. Debugging and testing are easier as well.
Other major improvements include server-side rendering. It allows us to do a lightening fast initial render and support for web crawlers (say hello to better SEO). Web workers – moving a lot of the Angular logic to a Web Worker allows the UI to update smoothly.
Angular 2 enforces better application architecture and design. All updates in Angular 2 are controlled. One way data flow from the application state into the components allows components to talk to each other without knowing too much about each other.
Technical Debt / Investment
Do the math!
What is your technical debt run rate? How much of your budget is going to technical debt? What is the net present cost of this?
Make your decisions based upon your situation. You need to minimize the impact on your organization.
Angular 1 came into the picture 3 years ago! As time passes, your code is going to be harder to migrate. You cane expect to change anywhere between 60% – 80% of your code in the future.
What impact would sticking/migrating have on your organization?
Risks of Upgrading to Angular 2
Refactoring code always carries an element of risk. You can break existing features in your large codebase or risk the delivery of future delivery moving forward.
Angular 1 represented the first phase of SPA architecture. It wasn’t perfect. Angular 2 has learned from the mistake made by its predecessor and offers a more robust way of building large scale applications.
You could fix a lot of the issues with the newer approach to Angular 1 (inspired by Angular 2 and React), or you might as well move to Angular 2.
What Should You Consider Before Making the Move?
If your product is at an early stage and you don’t expect to ship anytime soon, you should consider moving to Angular 2 immediately.
But, if you have a complex application running in a production environment, or are expecting to launch soon, you need a better plan to refactor your codebase.
Let’s go over some of the key factors that you should consider before upgrading.
Team Expertise in Angular 2
Most developers took days if not weeks to wrap their heads around Angular 1. Angular 2 does not pose the same problem. The class based code is easy for a new developer to wrap their head around.
Having said, nobody knows your team and product better than you. You need to make this decision based on the state of your product (in development, upcoming launch, application in production) and the time on your horizon.
If you are running on a tight schedule with a delivery coming up right around the corner, training your Angular 1 developers and refactoring your code in time isn’t going to be a cakewalk. I recommend sticking with Angular 1 at this point.
In most other scenarios, you’ll have enough time to either train your developers or hire developers externally to work with Angular 2.
The Difficult Case – How Should You Migrate?
Let’s say you have an application in production. A team that’s working round the clock to deliver the new features that users demand, and not enough capacity to take on a codebase migration.
1. What should you do?
First off, you need to think about the future. Your product shouldn’t turn into one that is phased out soon after being shipped. You’re reading this article because you know that your product has to be maintained over a longer period.
You need to think about the future. Moving from Angular 1 to 2 is clear, but how should you make the change?
You aren’t just migrating your code; you’re migrating your entire team. You’d be better off migrating your team first and then hopping aboard the Angular 2 train. Your team needs to be ready before you move your code.
2. How Can You Upgrade Your Team?
You need to keep two things in mind.
Firstly, the most important ingredient in learning Angular 2 is the component oriented architecture. Unlike Angular 1, Angular 2 requires you to organize your components in a very disciplined manner.
Most Angular 1 projects aren’t organized to fit into the Angular 2 paradigm. Most developers haven’t been trained to work this way either.
New build tools such as webpack, immutable data structures, and unidirectional architecture are a few important things that form a part of this new architecture.
Begin Your Technical Investment
Look outside Angular to meet your hiring needs. A lot of concepts in Angular 2 are used widely in the React community. This means that the best Angular developers at this point are quite familiar with React.
But, this does not mean that you can hire a React developer and expect him to migrate your Angular 1 code. Migrating the code requires knowledge of Angular 1.
The best solution, in this case, would be a mixed-team. You can enhance your existing Angular 1 team with developers from outside who bring in Angular 2 (or React) experience.
Approaches to Code Migration, Angular Upgrade
Before we talk about code migration, you need to ask yourself this – how well written is your Angular 1 project?
A lot of existing projects in a poor state. Most common problems include “$scope” all over your code and “fat” controllers (your code isn’t as modular as it could be).
Most projects don’t have much in terms of unit testing either.
The messier the codebase, the harder and more beneficial the migration will be. Regardless of how good your codebase already is, your application has a lot to gain in terms of performance.
Best way to started Upgrading to Angular 2?
You could take any one of these four approaches based on the state of your application, customers, team and organization.
1. Refactor Straight into Angular 2
If your code is well written, this approach will work best. Your team would work directly implementing Angular 2 components.
The app would run in hybrid mode during the update – Angular 1 and Angular 2 components would run in the same application. This is achieved using ngUpgrade – more on that later.
Ideally, once the components are in order, you will switch to Angular 2. For a well-written application, this should be a fairly quick process.
2. Refactoring Towards Angular 2
You can look at this approach as a step before the one described above. The goal is to make your application cleaner by eliminating unnecessary usage of “$scope” and reducing the length of your controllers.
You start by switching to directives throughout your application. Later these directives can be converted into components smoothly. We can call this the “ngUpgradable” approach.
You’d minimize the risk of moving your entire code base directly to Angular 2 and you can work with your existing Angular 1 team.
The only negative is that you’d temporarily miss out on the performance enhancements of Angular 2.
This is a conservative approach and works best if you want to avoid any potential risks of refactoring straight into Angular 2.
3. Rewrite All At Once
Sounds risky? It is. This is on the other side of the risk spectrum.
This approach only makes sense if you’re in a scenario where your app is very simple, or you are planning to rewrite the application from scratch anyway.
Unless you have a high-risk appetite, this approach is not recommended.
4. Rewriting and Refactoring in Steps
This is a balance between the first and second approach and one that fits well for most organizations.
First, we use ngUpgrade to run the application in hybrid (Angular 1 + Angular 2) mode. Then we go through all the code, and either rewrite the code to bring it closer to Angular 2 or refactor it – depending on what is more appropriate for that element.
The hybrid application will be deployed in production mode while the code is completely refactored.
Simply put, ngUpgrade allows you to use Angular 1 and Angular 2 components side by side. It allows the use of Angular 2 components inside Angular 1 and Angular 1 directives inside Angular 2.
This isn’t a plug and plays solution. The requirements that Angular 1 directives need to satisfy to be “plugged into” Angular 2 is fairly demanding. A messy codebase needs to be cleaned up first using the approach we described above.
Once the code is cleaned up and refactored into Angular 2 components, we need to switch to using the component router – Angular’s new router. You need to swap your router before you can switch fullscreen components to Angular 2.
You need an organized way to sweep through your code and rewrite / refactor it.
a. Services First Approach
We start by converting our Angular 1 services to Angular 2 services. We can then move on to refactoring components and pipes.
This is where we can increase test coverage for the entire application.
b. Screen by Screen Approach
Here, we refactor the code feature by feature. We convert small chunks of the application into Angular 2.
c. Bottom Up and Top Down Approaches
Using the bottom-up approach, we start converting smaller components into Angular 2 first.
Once again, starting with services is less risky. You can then proceed to components, refactoring things like buttons, date takers, what have you.
The final step of this process is upgrading to the new router and converting the full screen to Angular 2.
When introducing new sections, we can start thinking about introducing unidirectional architecture. Ideally, we’d want this to be a part of the migration.
Regardless of the state of your current application, the approaches mentioned will get your organization through the process of Angular upgrade.
Most companies should upgrade to Angular 2. The technical investment will pay off in performance improvements as well as maintainability and scalability of your code.
Start by upgrading your team and existing app architecture, clean up the code and refactor.