As developers, we often encounter challenges when tasked with introducing new features to an existing application, especially if the application had been built on an older technology stack.
One inevitable decision that we as developers have to make is whether we stay with the current stack or migrate to a modern stack that allows us to leverage newer technologies.
The road to this decision is layered with cost considerations, the development lift, available expertise, and time to market and if the decision is made to change the tech stack, then an inevitably related decision is whether to build the new interface in its entirety for release or release new features as they are developed.
Most developers would prefer building a new system from the ground up and not being bothered with the constraints, nuances and integration into an older technology, but what if I can show you a way to integrate new technology into an existing application with only a few lines of code?. Building a new application in its entirety and swapping out the old for a new and shiny 2.0 is often attractive but not always the best decision, especially if our end users are partially resistant to massive change.
This was the case when releasing new features for Virginia Credit Union. For good reasons, we added Angular to the technology stack and decided to build from the group up but selectively and cautiously released new features while still supporting the existing application.
Running Angular Inside of .Net
Let’s say you currently have a user interface written in ASP.Net. It works okay but it’s time to add new features, capabilities and you want to leverage a frontend frame like Angular. Most frontend frameworks, in this case, Angular, offer a modular structure, simplified MVC pattern, code consistency, declarative UI, and much more. Discussing the advantages and disadvantages of migrating an ASP.Net application to Angular is enough for its article but let’s say you want to be in the 44.3% of software engineers who use Angular for creating user interfaces (Stack Overflow Developer Survey 2017), but you can’t afford to wait 9 months to a year for the first iteration of your new standalone application to be ready.
Also let’s say there are parts of the application that, for good reasons, need to remain ASP.Net due to vendor constraints, so ideally you’re looking for a way to release new features developed in Angular inside an ASP.Net application to gradually replace features until the entire application is rewritten in Angular.
I know that’s a mouth full, but the solution is simple; Angular custom elements.
Manually Bootstrap Angular to an ASP.Net Application
During the Angular bootstrap process, the platformBrowserDynamic module is responsible for loading the application into the browser. The platformBrowserDynamic loads the root module by invoking the bootstrapModule and giving it the reference to our root module.
The root module must have at least one root component. The root component is loaded, when the module is loaded by the Angular. By default, the <app-root> is the root element in the index.html that Angular uses to bootstrap itself when running a normal standalone angular application, but what if we could declare a custom element, an element that exists on another page other than index.html? In this case, an ASP.Net page of our existing application.
This can be very useful in our above situation, where we want to inject an Angular application into an existing ASP.Net application.
For example, if we have a transaction page developed in Angular, we can wrap the transactions component inside a transaction module with a root element of <app-transactions> nicely placed inside our empty transactions.aspx and the possibilities become endless.
Injecting Angular Elements into ASP.Net pages
Given that we can declare our root module as seen in the paragraph above and an Angular application can have unlimited modules, nothing is stopping us from breaking our feature sets into modules and preparing them for manual bootstrapping inside of an existing ASP.Net application.
We can choose to keep the codebase together and use dynamic bootstrapping to simply inject specific modules onto specific pages or we can isolate every module in its codebase or repo and bundle the module as an Angular element to drop it into a page but at the end of the day, we’ll now have snippets of the new application written in Angular and ready for deployment into an existing ASP.Net application.
We can then continually develop more and more user features in Angular and gradually roll them out to users until the entire application is re-written or replaced by Angular.
Even though we changed the tech stack, we don’t have to build the new application in its entirety or to pull down the old application to implement the new, we simply add or replace new features module by module, component by component for quicker and phased delivery to end users in a truly agile manner.
Sign up for the Shockoe newsletter and we’ll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.