Angular

Migrating AngularJS to Angular

Published Jan 13, 2021

Updated Feb 16, 2023

8 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Introduction

There is still a lot of confusion around Angular and AngularJS. It has gotten better, but searching for "Angular" still provides ambiguous results.

This is a problem because AngularJS is on Long Term Support (LTS) mode. It entered LTS on July 1, 2018, for 3 years. It was granted a six-month extension due to COVID-19. Therefore, all support is expected to end on December 31, 2021, meaning Google will stop fixing bugs and providing support for AngularJS.

All Angular engineering effort will be focused on the latest version of Angular making it prudent that active AngularJS codebases are migrated to Angular this year.

This article will showcase different migration paths available to achieve this.

Big Bang Rewrite

By far, the easiest way to migrate a legacy codebase is to simply start fresh from the ground up. You won't have to worry about conflicting packages or supporting different versions of the same package.

You would simply use the latest Angular CLI to scaffold out a new app and begin working on re-implementing your legacy app features with Angular.

However, this is a significant engineering effort.

This approach is excellent for very small AngularJS apps. However, it can also be possible for larger codebases.

For larger codebases, you could set aside one or two developers to perform bug fixes and tackle production issues on the AngularJS app. You would inform customers that new features will be considered but will likely take some time to become available in the app. You would then concentrate the rest of your engineering effort on rewriting the app in Angular.

This allows you to support your current app as it stands whilst reaching feature parity with the new Angular version of the app.

UpgradeModule

UpgradeModule is a tool provided by ngUpgrade by Angular to aid in the migration process. It allows you to run a hybrid application, mixing Angular and AngularJS apps. There is no emulation; it runs both frameworks at the same time.

UpgradeModule provides us with two options on how we run our application. We can either run the AngularJS app and downgrade our Angular code into it, or we can run the Angular app and upgrade our AngularJS code into Angular.

The Angular docs provide incredible documentation on setting up the hybrid application (you can read more here). We'll cover the basics here.

Downgrading to run in AngularJS

Generally, AngularJS apps can be bootstrapped using the ng-app directive such as:

<body ng-app="myApp">
</body>

However, for ngUpgrade to take full effect you need to manually bootstrap AngularJS:

angular.bootstrap(document.body, ['myApp'], {strictDi: true});

The next step in running the latest Angular framework in the AngularJS context is to load the framework itself.

This involves an outdated setup process where we need to use SystemJS to set up our Angular framework. The Angular framework no longer uses SystemJS by default for loading the framework; however, they have written a guide on how to do this here.

We then set up Angular to provide it with a reference to the AngularJS App and more importantly, its Dependency Injector: $injector.

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { UpgradeModule } from '@angular/upgrade/static';

@NgModule({
  imports: [
    BrowserModule,
    UpgradeModule
  ]
})
export class AppModule {
  constructor(private upgrade: UpgradeModule) { }
  ngDoBootstrap() {
    this.upgrade.bootstrap(document.body, ['myApp'], { strictDi: true });
  }
}

Notice that this.upgrade.bootstrap has the same signature as angular.bootstrap.

The final thing to do now is to bootstrap the Angular framework, which is done easily with one line:

platformBrowserDynamic().bootstrapModule(AppModule);

Now we can create new Angular components and downgrade them into AngularJS.

Say we have an Angular component called HelloComponent. We use downgradeComponent provided by ngUpgrade to allow this component to be available to use in the AngularJS app:

import { downgradeComponent } from '@angular/upgrade/static';
import { HelloComponent } from './hello.component';

angular.module('myApp', [])
  .directive(
    'helloWorld',
    downgradeComponent({ component: HelloComponent }) as angular.IDirectiveFactory
  );

We can then use this in an AngularJS template:

<div ng-controller="MainCtrl as ctrl">
    <hello-world></hello-world>
</div>

Notice that the directive is registered in camelCase (helloWorld) but we use it in our HTML with kebab-case (hello-world).

You're all set up to start migrating your components to Angular and downgrading them to be used in AngularJS.

However, I like to think you'll agree that there is a lot of setting up here, and it leaves you with an Angular codebase that uses SystemJS to bootstrap and load your app.

Upgrading to run in Angular

We can take a different approach with ngUpgrade and UpgradeModule, however. We could lazy load our AngularJS app into an Angular app that was scaffolded by the Angular CLI getting the full benefit of the build tools and leaving us with a codebase in line with the latest Angular.

The Angular docs provide a great guide on setting up the Lazy Load Approach.

It involves four things:

An Angular Service to lazy load AngularJS and bootstrap the AngularJS App
A file providing an entry point for AngularJS and the AngularJS App
An Angular Component to render the AngularJS app (a wrapper component)
Telling the Angular router when to route within the AngularJS app

Once these are complete (the Angular docs really do explain this best), you can start creating new Angular components and downgrading them to be used in the AngularJS app similarly to how it was done in the previous section.

You also get the benefit of a more straightforward method to upgrade AngularJS services to be used within Angular:

You create a factory provider and add it to the providers array of your Angular Module:

export function myServiceFactory(i: any) {
  return i.get('my');
}

export const myServiceProvider = {
  provide: myService,
  useFactory: myServiceFactory,
  deps: ['$injector']
};

/* ... */

@NgModule({
    declarations: [MyComponent],
    providers: [myServiceProvider]
})
export class MyModule {}

This means you can focus on upgrading your AngularJS components first, then circling back to your services afterwards.

This approach allows you to use all the modern Angular tools as well as providing you with an option of splitting up your AngularJS into smaller modules and only loading them as required. It also allows you to focus on upgrading smaller chunks of the AngularJS app at a time.

Take a look at this folder structure for an example:

You would store the relevant AngularJS code for the feature in the corresponding angularjs folder. This means your team can focus on one feature at a time without losing any functionality for your customers.

Angular Elements

Another approach that is gaining some popularity is to use Angular's Web Component solution, called Angular Elements.

Angular Elements allows you to package up your Angular Component as a Web Component enabling it to be distributed and rendered in a plain old JavaScript context.

This is awesome for migrating AngularJS codebases. It means we can create an Angular Component, bundle it as a Web Component and drop it into our AngularJS codebase with less set up than the ngUpgrade approach.

This approach does have some drawbacks. We need a good build pipeline that will bundle the Angular Components, make them available, and include them into the AngularJS codebase so that they can be loaded and used in this context.

One approach to take that employs this would be to create two folders: one for your AngularJS codebase, one for your Angular codebase.

You would keep your AngularJS codebase as is. All new work would occur in the Angular codebase.

You can use the Angular CLI to scaffold out a monorepo. Each component you intend to upgrade would live in its own /projects folder (this is an Angular CLI workspace convention).

To do this, you can run the command:

ng generate application my-component

Next, you need to add Angular Elements to your workspace:

ng add @angular/elements --project=my-component

This would create a folder and accompanying files at /projects/my-component.

You would then create your component:

ng generate component my-component --project=my-component

This will scaffold out the component files you need.

Once you have finished setting up your component, you need to use Angular Elements to convert it to a Web Component.

Modify the app.module.ts at the root of /projects/my-component:

@NgModule({
    imports: [BrowserModule],
    declarations: [MyComponent],
    bootstrap: [],
    entryComponents: [MyComponent]
})
export class AppModule {
    constructor(private injector: Injector) {
        const myComponent = createCustomElement(MyComponent, {
            injector
        });
        customElements.define('my-component', myComponent);
    }

    ngDoBootstrap() {}
}

When we build our app, we need to copy the output into a public folder in our AngularJS codebase.

To build the elements file:

ng build --prod --project=my-component

This will produce output similar to:

Notice that it created 4 files: 3 JavaScript files and one CSS file. They contain hashes to allow for cache-busting. However, it would also be worth bundling these together and naming them related to the component.

We can do this with a simple node.js script (concat-elements-bundle.js):

const fs = require('fs');

const pathToComponent = './dist/my-component';

const javascriptFiles = fs.readdirSync(pathToComponent).filter(file => file.endsWith(".js"));

let fileData;
for(const file of javascriptFiles) {
  fileData += fs.readFileSync(`${pathToComponent}/${file}`);
}

const hash = Date.now();
fs.writeFileSync(`./dist/my-component/my-component.bundle.${hash}.js`, fileData)

We can run this on the command line using node:

node concat-elements-bundle.js

This will output something similar to:

my-component.bundle.1610106946217.js

We then need to copy this to a scripts folder in our AngularJS and include it using a script tag in our index.html file:

<script type="text/javascript" src="app/scripts/my-component.bundle.1610106946217.js"></script>

We can then use our component anywhere in our AngularJS app:

<div ng-controller="MyCtrl as ctrl">
    <my-component></my-component>
</div>

This approach allows us to incrementally upgrade components to Angular, using Angular's modern tooling without changing our existing app's set up much. Once all components are upgraded, we have to place the components together in an Angular app, completing the migration.

With a good CI Pipeline we _could _ automate the bundling and inclusion of the Angular Element in the AngularJS app, requiring even less work as the migration moves forward.

Best Practice for Upgrading

No matter the approach taken, one thing remains consistent between the two of them: how we tackle the migration.

Consider our application to be a tree of components. The closer to the root of the tree, the more complex and usually more coupled the components are. As we move down the nodes in the tree, the components should get simpler and be coupled with fewer components.

These components, the lowest hanging fruits, are ideal candidates for migrating to Angular first. We can migrate these components then use them in the AngularJS app where appropriate.

Let's say we have an AngularJS TodoList Component which uses an AngularJS Todo Component.

At this point, we can't really migrate the TodoList Component to Angular as we would have a dependency on the AngularJS Todo Component.

We can migrate the Todo Component to Angular first and use it in the TodoList Component. This makes it easier to migrate the TodoList Component as its dependency on the Todo Component is already an Angular Component.

We can use this approach when migrating legacy codebases. Start from the bottom and work our way up, and I would say this is the best approach.

Conclusion

With AngularJS losing support at the end of this year, it's worthwhile looking at migrating any legacy AngularJS codebases as soon as possible and figuring out a plan to do so.

Hopefully, this article has illustrated the different options available for you to do this and helped provide an approach to tackling migrating the components in your codebase.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Colum Ferry
JavaScript Developer and Enthusiast. Really enjoy working with Angular. Married with 2 amazing kids. Powered by Coffee.
@FerryColum @https://github.com/coly010

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

The HTML Dialog Element: Enhancing Accessibility and Ease of Use Dialogs are a common component added to applications, whether on the web or in native applications. Traditionally there has not been a standard way of implementing these on the web, resulting in many ad-hoc implementations that don’t act consistently across different web applications. Often, commonly expected features are missing from dialogs due to the complexity of implementing them. However, web browsers now offer a standard dialog element. Why use the dialog element? The native dialog element streamlines the implementation of dialogs, modals, and other kinds of non-modal dialogs. It does this by implementing many of the features needed by dialogs for you that are already baked into the browser. This is helpful as it reduces the burden on the developer when making their applications accessible by ensuring that user expectations concerning interaction are met, and it can also potentially simplify the implementation of dialogs in general. Basic usage Adding a dialog using the new tag can be achieved with just a few lines of code. ` However, adding the dialog alone won’t do anything to the page. It will show up only once you call the .showModal() method against it. ` Then if you want to close it you can call the .close() method on the dialog, or press the escape key to close it, just like most other modals work. Also, note how a backdrop appears that darkens the rest of the page and prevents you from interacting with it. Neat! Accessibility and focus management Correctly handling focus is important when making your web applications accessible to all users. Typically you have to move the current focus to the active dialog when showing them, but with the dialog element that’s done for you. By default, the focus will be set on the first focusable element in the dialog. You can optionally change which element receives focus first by setting the autofocus attribute on the element you want the focus to start on, as seen in the previous example where that attribute was added to the close element. Using the .showModal() method to open the dialog also implicitly adds the dialog ARIA role to the dialog element. This helps screen readers understand that a modal has appeared and the screen so it can act accordingly. Adding forms to dialogs Forms can also be added to dialogs, and there’s even a special method value for them. If you add a element with the method set to dialog then the form will have some different behaviors that differ from the standard get and post form methods. First off, no external HTTP request will be made with this new method. What will happen instead is that when the form gets submitted, the returnValue property on the form element will be set to the value of the submit button in the form. So given this example form: ` The form element with the example-form id will have its returnValue set to Submit. In addition to that, the dialog will close immediately after the submit event is done being handled, though not before automatic form validation is done. If this fails then the invalid event will be emitted. You may have already noticed one caveat to all of this. You might not want the form to close automatically when the submit handler is done running. If you perform an asynchronous request with an API or server you may want to wait for a response and show any errors that occur before dismissing the dialog. In this case, you can call event.preventDefault() in the submit event listener like so: ` Once your desired response comes back from the server, you can close it manually by using the .close() method on the dialog. Enhancing the backdrop The backdrop behind the dialog is a mostly translucent gray background by default. However, that backdrop is fully customizable using the ::backdrop pseudo-element. With it, you can set a background-color to any value you want, including gradients, images, etc. You may also want to make clicking the backdrop dismiss the modal, as this is a commonly implemented feature of them. By default, the <dialog> element doesn’t do this for us. There are a couple of changes that we can make to the dialog to get this working. First, an event listener is needed so that we know when the user clicks away from the dialog. ` Alone this event listener looks strange. It appears to dismiss the dialog whenever the dialog is clicked, not the backdrop. That’s the opposite of what we want to do. Unfortunately, you cannot listen for a click event on the backdrop as it is considered to be part of the dialog itself. Adding this event listener by itself will effectively make clicking anywhere on the page dismiss the dialog. To correct for this we need to wrap the contents of the dialog content with another element that will effectively mask the dialog and receive the click instead. A simple element can do! ` Even this isn’t perfect though as the contents of the div may have elements with margins in them that will push the div down, resulting in clicks close to the edges of the dialog to dismiss it. This can be resolved by adding a couple of styles the the wrapping div that will make the margin stay contained within the wrapper element. The dialog element itself also has some default padding that will exacerbate this issue. ` The wrapping div can be made into an inline-block element to contain the margin, and by moving the padding from the parent dialog to the wrapper, clicks made in the padded portions of the dialog will now interact with the wrapper element instead ensuring it won’t be dismissed. Conclusion Using the dialog element offers significant advantages for creating dialogs and modals by simplifying implementation with reasonable default behavior, enhancing accessibility for users that need assistive technologies such as screen readers by using automatic ARIA role assignment, tailored support for form elements, and flexible styling options....

Oct 25, 2024

4 mins

HTMLJavaScript

Learning Paths for Next.JS Developers with Ankita Kulkarni

In this video, Rob Ocel and co-hosts Tracy Lee, Adam Rackis, and Danny Thompson talk with tech educator Ankita Kulkarni about her journey from engineering leader to full-time educator. Ankita shares insights on teaching Next.js, bridging practical knowledge gaps, and helping developers tackle real-world challenges. They discuss Next.js as a React-based framework, its benefits, and the challenges it presents for beginners. Chapters - Introduction to the Podcast and Guests 00:01 - Meet Ankita Kulkarni, Tech Educator 00:26 - Ankita's Transition to Full-Time Education 01:41 - Teaching Practical Knowledge in Next.js 03:19 - Effective Methods for Teaching Next.js 05:27 - Challenges of Being a Full-Time Educator 07:48 - Balancing Broad and Specific Examples 09:54 - Embracing Mistakes as a Teaching Tool 12:13 - Pair Programming and Mentorship 14:00 - Discussion on Next.js and Framework Adoption 16:48 - Advantages and Challenges of Next.js 18:12 - Choosing the Right Framework for Your Needs 20:35 - Impact of Next.js in React Documentation 22:26 - Learning Paths for New Developers 23:24 - The Rise of Full-Stack Web Development 25:09 - Benefits of Frameworks Abstracting Complexity 26:27 - OpenNext and Deployment Flexibility 28:06 - Ankita's Excitement for New Next.js Features 30:35 - The Future of Next.js Without Vercel 32:16 - Final Thoughts and Where to Find Everyone Online 34:21 Follow Ankita Kulkarni on Social Media Twitter: https://x.com/kulkarniankita9 YouTube: https://www.youtube.com/@kulkarniankita Sponsored by This Dot: thisdot.co...

Nov 12, 2024

2 mins

NextJSJavaScript

NgRx Facade Pattern

NgRx Facade Pattern The NgRx Facade Pattern was first introduced by Thomas Burleson in 2018 and has drawn a lot of attention in recent years. In this article, we will discuss the pattern, how to implement it in Angular and discuss whether or not we _should_ implement it. What is NgRx? First, what is NgRx? NgRx is a state management solution for Angular built on top of RxJS which adheres to the redux pattern. It contains an immutable centralized store where the state of our application gets stored. - We select slices of state from the Store using Selectors, which we can then render in our components. - We dispatch Actions to our Store. - Our Store redirects our Action to our Reducers to recalculate our state and replaces the state within our Store. See the diagram below for an illustrated example: This provides us with a tried and tested pattern for managing the state of our application. What is the Facade Pattern? Now that we know what NgRx is, what is the Facade Pattern? Well, what _are_ Facades? Facades are a pattern that provides a simple public interface to mask more complex usage. As we use NgRx more and more in our application, we add more actions and more selectors that our components must use and track. This increases the coupling between our component and the actions and selectors themselves. The Facade pattern wants to simplify this approach by wrapping the NgRx interactions in one place, allowing the Component to only ever interact with the Facade. This means you are free to refactor the NgRx artefacts without worrying about breaking your Components. In Angular, NgRx Facades are simply services. They inject the NgRx Store allowing you to contain your interactions with the Store in the service. How do we implement it? To begin with, let's show a Component that uses NgRx directly: ` As we can see, this depends a lot on interactions with the Store and has made our component fairly complex and coupled to NgRx. Let's create a Facade that will encapsulate this interaction with NgRx: ` It's essentially everything we had in the component, except now in a service. We then inject this service into our Component: ` By implementing the Facade and using it in our Component, our component no longer depends on NgRx and we do not have to import all actions and selectors. The Facade hides those implementation details, keeping our Component cleaner and easier tested. Pros What are some advantages of using Facades? - It adds a single abstraction of a section of the Store. - This service can be used by any component that needs to interact with this section of the store. For example, if another component needs to access the TodoListState from our example above, they do not have to reimplement the action dispatch or state selector code. It's all readily available in the Facade. - Facades are scalable - As Facades are just services, we can compose them within other Facades allowing us to maintain the encapsulation and hide complex logic that interacts directly with NgRx, leaving us with an API that our developers can consume. Cons - Facades lead to reusing Actions. - Mike Ryan gave a talk at ng-conf 2018 on Good Action Hygiene which promotes creating as many actions as possible that dictate how your user is using your app and allowing NgRx to update the state of the application from your user's interactions. - Facades force actions to be reused. This becomes a problem as we no longer update state based on the user's interactions. Instead, we create a coupling between our actions and various component areas within our application. - Therefore, by changing one action and one accompanying reducer, we could be impacting a significant portion of our application. - We lose indirection - Indirection is when a portion of our app is responsible for certain logic, and the other pieces of our app (the view layer etc.) communicate with it via messages. - In NgRx, this means that our Effects or Reducers do not know what told them to work; they just know they have to. - With Facades, we hide this indirection as only the service knows about how the state is being updated. - Knowledge Cost - It becomes more difficult for junior developers to understand how to interact, update and work with NgRx if their only interactions with the state management solution are through Facades. - It also becomes more difficult for them to write new Actions, Reducers and Selectors as they may not have been exposed to them before. Conclusion Hopefully, this gives you an introduction to NgRx Facades and the pros and cons of using them. This should help you evaluate whether to use them or not....

Feb 9, 2021

4 mins

AngularNgRxJavaScriptTypeScript

Build Facial Recognition and Chatbot AIs using TypeScript with Jack Herrington

In this JS Drop, Danny Thompson is joined by YouTuber Jack Herrington to explore a unique TypeScript and AI project that lets you recognize TV show characters in real time. Just point your camera at a character, and instantly get their details or even chat with them as if they were real! Jack walks through the tech, explaining how client-side face recognition and server-side AI work together to make this possible using the Versal AI library. They discuss prompt engineering, building efficient APIs, and ensuring smooth, interactive AI responses. Jack also shares potential real-world applications, from entertainment to security. Chapters - 0:32 Project Overview – Jack explains the AI-powered character recognition project - 2:17 Setting Up the Project – Overview of how the application is structured and initial setup - 3:04 Client-Side AI – How face detection and character recognition work on the client side - 5:12 Switching to Server Side – Jack demonstrates server-side AI and setting up API endpoints - 8:20 Explaining AI Tooling – How tools and prompts are used to give context to the AI - 10:01 Detailed Prompt Structure – Breaking down the prompt and character context for AI responses - 12:40 Client-Server Interaction – Using the Versal AI library to manage streaming responses - 15:09 Handling Character Data – Training the AI on specific character images and details - 18:15 Practical Use Cases – Discussing potential real-world applications for the face recognition tool - 21:34 Challenges and Lessons Learned – Jack shares obstacles he faced and how he overcame them - 25:45 Building the API – Tips and considerations for creating reliable API endpoints - 28:40 Handling User Inputs – Testing unexpected questions and how the AI responds - 32:00 Using Advanced AI Models – Jack talks about choosing GPT-4 and issues with smaller models - 35:47 Introducing ProNextJS.dev – Jack discusses his new Next.js course, covering advanced topics - 37:20 Closing Thoughts – Danny and Jack wrap up with final thoughts and a link to the GitHub repo Follow Jack Herrington on Social Media Twitter: https://x.com/jherr Linkedin: https://www.linkedin.com/in/jherr/ YouTube: https://www.youtube.com/@jherr Sponsored by This Dot: thisdot.co...

Nov 11, 2024

2 mins

AIArtificial Intelligence

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Migrating AngularJS to Angular

Introduction

Big Bang Rewrite

UpgradeModule

Downgrading to run in AngularJS

Upgrading to run in Angular

Angular Elements

Best Practice for Upgrading

Conclusion

Colum Ferry

You might also like

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

Learning Paths for Next.JS Developers with Ankita Kulkarni

NgRx Facade Pattern

Build Facial Recognition and Chatbot AIs using TypeScript with Jack Herrington

Let's innovate together!

You might also like

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

Learning Paths for Next.JS Developers with Ankita Kulkarni

NgRx Facade Pattern

Build Facial Recognition and Chatbot AIs using TypeScript with Jack Herrington