Alternate IFRAME Migration - Method

AngularJS (and modern Angular) applications are typically built using multiple third-party dependencies. During our migration process, some of these third-party dependencies can be directly absorbed or switched out with an Angular equivalent without a problem.

However, in some cases these dependencies may clash with each other when we run our application in hybrid mode since they will be sharing the same global namespace. This is undesirable and can introduce many issues during our migration process. So what can we do about this?

Consider the example where we have an AngularJS application running bootstrap version 2.3.2.

To deal with this we can do either one of the following:

1. Maintain the same Bootstrap version over to Angular

Although this approach may work, this is still backward thinking. If your main reason to migrate your application is to move away from legacy code, then this is definitely not the way forward.

2. Upgrade Bootstrap version before migration

This approach definitely works but the downside is, there will be a lot of throwaway code from your AngularJS application that you have written to maintain compatibility with the Bootstrap version you upgraded to.

What we ideally want in a solution is the capability to directly migrate our dependent modules to their latest versions while we complete the migration to modern Angular.

Unfortunately, this is not something that can be easily done in the ngUpgrade approach.

Not all AngularJS applications follow best practices and are perfectly architectured. What this means is that, before we can start our migration process, we need to re-factor our code and fix any architectural issues that our application might have.

In fact, we saw this in our migration course as well; We dedicated most of the initial steps to re-write our application before starting our migration to Angular.

Unfortunately, this is easier said than done. If you are working on an AngularJS application the odds are that it has years and years of investment with lots of complexities that are not easy to re-factor out. It might even be the case that re-writing the application completely in Angular could be a better option than to re-architecture it to fit a migration.

So what can we do?

Consider the following application where we have a simple counter written in Angular.

Now, if we switch to AngularJS by clicking on the “AngularJS” button at the top, we switch to an AngularJS version of the same application within an iframe.

If you analyze the html source of this AngularJS application, you will see that our AngularJS application code is in fact injected into an iframe.

This isn’t one application, but two completely separate applications with one (the AngularJS application), being “iframed” into the other (the Angular application). This method allows our AngularJS application to remain exactly as it is, without any modifications whatsoever, inside an Angular host.

What we can do next is migrate our AngularJS application one route at a time, over to Angular. If the routes have been migrated over to Angular, the host application will handle it. If not, the component rendering will remain with the AngularJS application.

Now this is not a fully fledged solution, but an idea that you can use as inspiration to modify and apply to your own AngularJS migration challenge. In the next lecture we will see how Route Ownership and Shared State is handled in this Iframe Migration Method.