#native_company# #native_desc#

Alternate IFRAME Migration - Method

Lecture Objective

In this lecture, we will discuss an alternative migration strategy that you could use to migrate your AngularJS application.

Why do migrations fail?

Two of the biggest reasons for AngularJS application migrations to fail are,

  1. Other baggage

  2. Clean house

Lets see what each of these means in the context of an AngularJS migration.

Other baggage

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.

48 img 001
Figure 1. Dependencies across AngularJS and Angular applications

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?

48 img 002
Figure 2. A hybrid application running their own dependencies

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

48 img 003
Figure 3. Using the same Bootstrap version across a migration

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

48 img 004
Figure 4. 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.

48 img 005
Figure 5. Direct migration of dependencies to their Angular versions during migration

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

Clean house

48 img 006
Figure 6. Clean house — the road to Angular

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?


My solution for all these problems, which I call the Iframe Migration Strategy is based on… (you guessed it right!) iframes. The idea is to “iframe” in legacy AngularJS application to an Angular host as shown in the Figure below.

48 img 007
Figure 7. A hybrid application running their own dependencies

To better understand this, lets take a look at a demonstration.


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

48 img 008
Figure 8. Angular counter application

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.

48 img 009
Figure 9. Angular counter application

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.

48 img 010
Figure 10. Angular counter application

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.

Caught a mistake or want to contribute to the book? Edit this page on GitHub!

Advanced JavaScript

This unique course teaches you advanced JavaScript knowledge through a series of interview questions. Bring your JavaScript to the 2021's today.

Level up your JavaScript now!