Problems With Angular Migration

Introduction

It would seem that this is the easiest way to solve the problem—by avoiding it. But this is the wrong way. By avoiding the problem, we only postpone its solution. And over time, the problem will not go away on its own and will just hang over you and put pressure on you. But in my opinion, it is easier to get rid of such a burden immediately.

There is one safe way to do this—to get acquainted with all the possible difficulties that may befall you and prepare well to meet them.

This rule works everywhere, of course, it also works in programming, and in particular when in angular development or migrating from AngularJS to Angular. I will introduce you to the main problems that await you on this long-term path (for some lucky folks, it's short-term) and give examples of how to solve them.

What Is Migration?

But first, you will find brief information about the migration itself, of course. AngularJS to Angular migration is a process of transition from the old framework, which is already limping on one leg, and on which updates are no longer released to the modern and popular framework. Different migration paths differ in the size of applications, the pace of migration, opportunities for simultaneous work of both frameworks, and so on.

WARNING!

The first thing I'm going to do is just to give you a little bit of a warning.

I should mention that AngularJS to Angular migration is going to be hard work. Every AngularJS application is different; every single one is unique. Of course, there are certain plans, certain work templates, but there are also a lot of such cases that are not described in the manuals and the answers to which you will have to look in the forums.

So, in this section, I'm going to cover a few key issues. I mean issues that are perhaps common enough to warrant just a quick explanation, for how you may want to solve them during AngularJS to Angular migration.

The Problems During Coding

I think two of the most popular questions are:

• What to do with all of $cope.$watches in the AngularJS application
• And what to do about all of the emit and broadcast functionality

I believe in one fact that become clear to me much later in my career as an AngularJS developer. The fact is that if you stole off a lot of $cope.$watches in your application it is probably a sign that you have poor architecture. Some people's applications use this so much that they just struggle to even figure out how to migrate to Angular because Angular doesn't have these concepts at all.

There is a temporary solution to the second issue. If you are running in hybrid mode and you need to communicate between an AngularJS entity that's sending out an event and Angular wants to capture the event just temporarily. Of course, there is a solution and it's just by essentially temporarily upgrading an Angular service and AngularJS service. So it's actually the root scope that we can use to emit and broadcast.

It is not a permanent solution; when you want to eventually drop AngularJS, you do have to find an architectural solution for this. But if you just need something that works during the process of migration, it is the best choice for you.

Why Do Migrations Fail?

In my experience, the biggest reason for the failure to migrate an AngularJS application is that there's always other baggage to deal with. Besides, there is this other concept I call a clean house. 

So, we don't build our Angular applications in isolation. Typically an Angular application and also AngularJS application use a whole number of other third-party modules or dependencies. We use them to build our application and we cannot deal without them. Moreover, in AngularJS, we use a whole lot more dependencies. In my experience of migrating, some of these modules were absorbed and some of them were not. 

Sometimes when you migrate you also want to update some of these dependent libraries. The problem is that we're not running two separate applications in hybrid mode; we're running one application and both those applications. And that one application is sharing the same global namespace, the same memory on the computer. Consequently, they have to share their baggage. 

What are our options? The first option is just to keep the baggage the same. So we don't bother migrating to Angular2 Bootstrap4 and we migrate our AngularJS application to Angular5. We now have an Angular 5 application that's using Bootstrap2—a pretty depressing situation to be in. 

What are some of the other options? Well, one of the things we can do is first migrate to Bootstrap4 in our AngularJS application and then we migrate to Angular5 (or whatever the modern version of angular is right now).

That's great but in this situation you write a lot of throwaway code, you change all of your directors, all of your templates. Finally, you're just gonna throw away most of that stuff when you eventually migrate to Angular5.

The other issue is the clean house. When AngularJS first came out, we had no idea how to architect a good application. We used to use controllers instead of components, and so on. These are things that make migrating much harder because these don't have direct analogies and because of this, you have to rewrite your code in order to start the process of migration. In a way, your architecture has to be quite good. It's very difficult to migrate from and at the same time be fixing architectural issues in your AngularJS application. You have to have fixed them all before you migrate.

Summary

I would like to summarize the discussed problems you may encounter on the migration path:

• lacks documentation or support online
• can run into many errors 
• may have to deal with old clunky code and old problems

Still, it is always only your choice whether to migrate or not. And you need to weigh all the pros and cons, repeatedly considering your actions. The process is not very easy but is also not impossible.