If you’ve ever sifted through job boards or even stackoverflow when it comes to Angular, you will see people use the terms “AngularJS” and “Angular” interchangeably. Or atleast that’s what it can sometimes appear to be. But AngularJS and Angular actually refer to two very different versions of Angular. While learning one basically gets you half way to learning the other, they are not necessarily interchangeable. So what’s the difference?

AngularJS Is Angular 1

Before we jump into the actual differences between AngularJS and Angular. The first thing you need to know is that the term “AngularJS” is typically used to refer to the very “first” version of Angular, Angular 1. When Angular 2 rolled out, it had tonnes of “breaking” changes from version 1. Infact it was a completely different architecture! Where Angular 1 used things like Controllers and used Scope/Rootscope, Angular 2 did away with these and made everything in your app a “component”.

Naturally some were adverse to such a hard shift and given that many applications were already written in version 1, people didn’t want to have to go through and update their entire application architecture so they stuck with it. Even as further versions of Angular rolled out (Angular 4, 5, 6 etc), Angular 1, now called AngularJS, received it’s own updates with things like performance boosts and security upgrades. For some, this meant AngularJS was still a very viable alternative to creating a Single Page App without having to re-learn a new framework.

Feature Comparison Between AngularJS And Angular

As mentioned above, Angular 2 introduced a completely new architecture of “everything” being components. Because of this you could almost say it’s a different JS framework, but I’ll try and list out a couple of important differences between the two versions.

  • Angular uses Typescript (as default but you can use Javascript also) while AngularJS uses plain Javascript.
  • Angular makes everything a “component” and you use these as blocks to create your app. While AngularJS is primarily MVC (Model-View-Controller) based.
  • Angular makes uses of it’s own CLI to create components, run tests, serve the app etc while AngularJS does not have a CLI at all.
  • Angular has it’s own inbuilt packaging system using Webpack while AngularJS requires you to roll your own (Often Gulp, but you can also use Grunt or Webpack)
  • AngularJS requires different attributes to say whether you want two way or one way binding (e.g. ngModel vs ng-bind) whereas Angular just uses [] or ()
  • Angular has a component based CSS encapsulation concept, AngularJS does not
  • Angular supports server side rendering, AngularJS does not

This is by no means an exhaustive list. Realistically, I could list out many “annoying” gotchas with AngularJS that were fixed in Angular 2+. For example data binding in Directives is a right pain to learn in AngularJS and is by no means intuitive, you need to learn crazy text symbols to work out how multi directional binding works :

Whereas in Angular this is just so much more intuitive.

Should You Start A New Project On AngularJS Or Angular?

Angular. 100% Angular.

On July 1st 2018, AngularJS entered into lifetime support mode. This means it’s not actively being worked on (feature wise), and new releases will only contain security fixes or critical bugs caused by a new browser version. This is expected to last until June 2021 at which point support will end. So at best the AngularJS you have right now will continue to be the same in the future, and at worst from mid 2021 onwards your framework will no longer be “supported”.

Angular just fixes so many issues with AngularJS with a very small learning curve. If you know AngularJS already, then getting started on Angular won’t be a hassle at all. If you are starting fresh and thinking of building your first SPA, there is no reason to pick a framework with notable gotchas that will run out of support in a years time.

Yes, we should always be doing unit tests, E2E tests, integration tests, and whatever other sort of tests are the flavor of the month. But you might also find yourself working on a proof of concept that tests are just going to be overkill on.

Even so, each time you run an ng generate command, you end up with an annoying spec file that isn’t too hard to delete, but is just hella annoying to have to do each time. Luckily Angular provides a way to turn off spec files via the CLI. Let’s take a look.

When Creating A New Project

When creating a new project, there is a way to skip the entire rest of this tutorial by one simple flag.

When creating your new project, simply pass the –skip-tests flag and “theoretically” it should skip *ALL* tests right?

Well wrong (As of Angular 8). You will probably see the following fly by :

So as it turns out there is an open bug on the Angular Github Repo for this exact issue : https://github.com/angular/angular-cli/issues/9160. Personally I think it makes sense that when you say “Hey, I’m not doing tests”, that you actually mean it, but Angular gonna Angular.

So if it still creates the e2e folders, what does it actually do when you pass –skipTests? Well it adds the following into your angular.json file :

What it’s essentially doing is saying “Hey, when I create these things, don’t create tests”. So for example if we run the following command :

It won’t generate the spec file along with it. Awesome!

When Working On An Existing Project

You may have already created your project so passing the –skipTests flag to the ng new command isn’t going to cut it. So you have two ways you can work around this (Or really one if I’m being honest).

The first way is less than ideal because 9 times out of 10 you forget to pass the flag. That is, when you run ng generate , you can pass skipTests in there :

Note that in older versions of Angular this was a spec flag that you passed true or false in. This has now been deprecated but if you are on an old version of Angular it will look like so :

It’s quickly going to become a headache to always pass this into your generate commands. So a better way is to take the above schematics JSON that we talked about in the “When Create A New Project” section, and put that into your angular.json.

For example, if I don’t want new components generating a spec file, we can add the following to our angular.json file :

I’ll also note that you can pick and choose where you do this. For example you could disable tests for components only, but still generate tests for your services, pipes and guards.

The best way I’ve found to get the JSON just right is to create a brand new project in another folder using

And then copy and paste over the JSON you need. This will also give you a good idea of what how fine grain you can go when turning off tests (Or not turning them off as it might be).

In almost all of my Angular projects, one of the first things I add is a simple AppConfig service that allows me to swap out configurations on the fly for different environments. In most cases, this is so that I can set a different base API endpoint for my different environments, and have them swapped in at release time. Let’s jump into it!

Why Not Just Use Angular Environments?

So Angular actually has an inbuilt concept of “environments” (more info here) that is pretty similar to a typical appconfig setup. But the main issue is that this environment is also tied to individual builds. In modern day scenarios we want to build *once* and release multiple times. If our app settings are swapped out/configured at build time, this doesn’t afford us the ability to only build once and deploy multiple times. Instead we are building a different distribution for each environment.

Instead, I would highly recommend keeping Angular Environments for settings that you want to have at build time (e.g. Turn off Debug), rather than setting up individual settings between Dev,  Test,  Production etc.

App Config Is Not A Secret Store

The next thing I want to touch on is that no matter what we do in Angular, it’s still a front end web technology. That means that, even if we obfuscate things a bit, any user can still view the source code. In this tutorial, we are using a publicly available JSON file as our application configuration file, so even more so, it’s not a secret store. Do not put anything in there that you don’t want shared to the public.

Really, in most cases we are just going to be putting in there a API base endpoint and maybe a couple of other small config params that change markup. But nothing like like DB Connection Strings, authentication tokens etc.

Create Our Config Files

The first thing to do is to create a couple of configuration files in a safe directory. By safe I mean that Angular will just take the directory as a whole and output it when building. We don’t want Angular to do anything with our config files, just copy them when we build.

For that reason I typically choose the assets  folder which is created when you create a new Angular project from the CLI.

So in a folder at /assets/config  I create two files. The first is just called app-settings.json with the following :

And then I create another called app-settings.production.json with the following :

So that’s our config files ready to go!

Creating The AppConfig Service

Next create a new service using the Angular CLI called AppConfig. Then replace all the code with the following :

Let’s walk through this a little, even though it’s pretty simple.

We have a method called loadAppConfig that essentially calls our config files we created earlier, then loads them into a local appConfig object that is basically a dynamic type.

We then have a property called apiBaseUrl that will return the apiBaseUrl that we just retrieved from our json file.

But there’s a problem. Before we can retrieve the apiBaseUrl, we first need to call loadAppConfig. And we only really want to do this a single time to load the file into memory, after that any further calls to load the json file are a complete waste. We could write some code in here with a boolean to check if we have loaded the config already, and if we haven’t to load it, and then continue. But that’s naff.

Luckily Angular already has a feature to help us!

Using APP_INITIALIZER To Load Configuration

In a previous post we talked about how to use APP_INITIALIZER in Angular to do a “one time” activity when the Angular app bootstraps for the first time. If you haven’t come across this feature before, I highly recommend going to read it because the following might not make much sense otherwise : Using The APP_INITIALIZER Token To Bootstrap Your Application. 

All we need to do is head to our main app.module.ts, and add a line to our providers array that looks like so :

What this does is say, when our app is started, can you please call the following method. Our loadAppConfig method actually returns a promise anyway, but our application will wait until this promise completes before continuing on.

It may seem backward to wait until our configuration file loads to continue loading our application. Won’t the startup time be noticeable? Maybe. But we also can’t be sure what will be calling the config service and, more importantly, when. So it’s better for us to just load everything up front and be ready when things hit us.

Swapping Configurations At Release

Now comes the easy, but… different… part. By different I mean this next step will totally depend on how you release your application. The nuts and bolts of it is that when you release to say, production, you will need to rename the file app-settings.production.json to app-settings.json. That way when your service loads your configuration file, it’s the right one for that specific environment.

For me, because I’m doing releases from Azure Devops, I wrote a quick piece of powershell to simply rename the file. But you can use any sort of script, or maybe even an inbuilt step in your release pipeline can do it. Either way, renaming the file is the last step and you are ready to go with your brand new app config service in Angular!

Angular has a great CSS feature called “View Encapsulation”. It means that each component can have it’s own CSS that is encapsulated and applied to only that particular component/view. This does away with having to have great big long CSS declarations to try and narrow down the element you want to style. For example you probably have seen gnarly things like :

With Angular’s View Encapsulation that is no more (Well… Atleast most of the time).

But you may come across some situations where the view encapsulation gets in your way. Where you know the element you want to style, but the additions in the shadow dom are making things a headache. Luckily Angular adds in a couple of CSS Pseudo Elements that help you “break out” when you need to. These include :host, :host-context and ::ng-deep. Today we’ll do a dive on :host.

:host In A Nutshell

Imagine I create a component called “my-component” that’s pretty darn simple :

Now if I want to style the component itself? How do I do that? How can I style the <app-my-component>  tag? A beginners take might be to try some CSS/SASS like so :

After all, I’m using the name of my tag inside itself so hopefully it should be recognized. Wrong. Angular view encapsulation means I can only style things “inside” the component, but not the component itself. Unless I use the :host pseudo element of course :

Remember this goes *inside* the components style file, and not in the root etc. Using :host I am able to self style the component! It’s almost like using the “this” keyword in Angular CSS syntax.

What Goes On Under The Hood?

When your view is compiled down, your components are given unique attributes to encapsulate styles from one other. So in my example, app-my-component actually gets output looking like :

The way it works (in a simple way) is that each component is given an _nghost-unique-id . Each element that lives inside that component is then given an _ngcontent-unique-id  . Where the unique-id on the ngcontent label matches that of the parent nghost. Pretty smart stuff!

So that goes a ways to explain why when we try our beginners attempt of just using the component tag :

It doesn’t work because the generated CSS actually looks like :

So notice that it’s saying our tag should have an _ngcontent tag with a specific id but we are actually looking for the same tag with an _nghost.

When we check how it generates and outputs the :host tag, it looks like :

Makes sense! It outputs the exact tag it knows our component will have, allowing us to style the component itself, not just it’s children.

If you’ve ever tried to put a placeholder attribute on a date input like so :

You know it doesn’t work.

Instead what you end up with is the field being pre-populated with “dd/MM/yyyy” which is incredibly annoying! But there is actually a way to get the placeholder working by instead making the input function as a textbox until clicked, and then quickly swapping it to act like a date input.

First we need to change out input to be of type “text” like so :

We are now going to create a new directive. In my case I named it DynamicDateInputDirective. The contents of which is :

What does this do?

  • We use the HostListener to bind to the focus event, on focus, we ensure that the field is of type “date”.
  • We then use the HostListener to bind to the blur event (So focus is moving away from the field). We check to see if the field is empty, if it is, return it to the “text” type. What this means is if someone clicks into the field but doesn’t enter anything and moves away, we keep our placeholder.

You can then add the directive to your text input :

Not using Angular? The paradigm is the same if you are using React, jQuery or even Vanilla JS. On focus you need to change your text type to date, and then on blur you need to do the reverse (Remembering to only do it if the value is empty).

Every “control” in Angular has EventEmitters called statusChanges  and valueChanges . The former is whether a control is “valid” so will emit an event every time a control changes from invalid to valid or vice versa. valueChanges  is when the actual control’s “value” changes. In most cases this is going to be a form element so it will be the value of the textbox, checkbox, input etc. In a custom component’s case, if you implement ControlValueAccessor, then it’s going to be the “value” of your control as bound by the ngModel.

In anycase, I came across an interesting scenario in which I needed to “subscribe” to changes when a control was “touched”. To my surprise, there is currently no event that is emitted when a control is touched – or when it’s status of pristine/dirty is changed. It’s actually pretty bonkers because typically when showing error messages on a form in Angular, you will make liberal use of the “IsDirty” or “IsTouched” properties. So being able to “listen” for them seems pretty important. Ugh. Time to Monkey Patch.

What Is Monkey Patching?

Monkey Patching is a technique to change or modify the default behaviour of code at runtime when you don’t have access to the original code. In our case, we want to be “notified” when “markAsTouched” is called. To do so, we need to modify the actual method of “markAsTouched” to emit an event/run a custom piece of code *as well* as do it’s regular method.

If you are interested in reading more about Monkey Patching, there is a great article (In Javascript no less) on the subject here : audero.it/blog/2016/12/05/monkey-patching-javascript/

Monkey Patching MaskAsTouched/Pristine/Dirty

To make this work, the first thing you need is a reference to the *control* that you are trying to listen for the touched event on. This could be done using ViewChild if you are looking for a child control on the page. To get the “self” control (e.g. in a custom component), a common pattern is to modify your constructor to inject in the “Injector” class which you can use to get the NGControl instance of yourself. You need to do this in the ngAfterViewInit method.

OK so we have the reference to the control. Time to patch things up!

Let’s walk through this code.

  • First we get a reference to ourselves. This isn’t necessarily required, but it’s highly likely we may want to refer to local variables/properties, and inside our function we lose scope of “this”.
  • We store the original “markAsTouched” method from our control reference. This line will obviously differ slightly on how you are referencing the control you want to patch.
  • We then set the markAsTouched method to a new function, that then itself runs the original method (e.g. Run Angular’s standard “markAsTouched”).
  • We can then run our extra code as required. This may be to raise an event on an EventEmitter, set another variable, run a method, whatever!

In my case, when my custom component was touched, I wanted to then manually “touch” another child component. So my full code looked like :

We can use this method to do the same for markAsPristine, markAsDirty, or actually any other method that Angular for unknown reasons doesn’t give us an event for.

Beware Infinite Loops

I would suggest when you do your first monkey patch, be liberal with your console.log statements. I found pretty quickly when trying to touch another control from within my monkey patched markAsTouched method, that I created an infinite chain of touching. It’s super easy to do so you’ll need to be extra careful.

When it comes to running “one off” startup methods when your Angular Application starts, everyone will tell you to use the “APP_INITIALIZER” token. That’s all well and good to be told that, but when you actually check the documentation, it’s a little sparse…

Admittedly there is a bit more on the token scattered around in other documentation pieces, but they are surprisingly hard to find and again, typically only lightly touch on actual real world usage. So consider this a beginners guide on how to use APP_INITIALIZER in your own app.

The Basics

The first step is to create our startup function. For the purposes of this article, I’m going to create a simple function that itself, returns a function to run.

It’s important that the function itself returns a function!

In our main module (typically AppModule), we want to add a provider to our NGModule decorator. For example :

Ignore the fact I don’t have any declarations, I’ve removed them so it doesn’t clutter things up. Now a couple of things to note here.

  • We are adding a provider with the key of APP_INITIALIZER
  • We are setting the “multi” flag to true as we may have multiple APP_INITIALIZER’s to run.
  • And finally we are telling it to use the startmeup method to create the method we want to run.

Running our application now, we should see a console message of “Started!” as soon as the page loads.

UseValue vs Use Factory

It may look strange for our startup method to itself return a method. It seems a bit silly to box things up like that. Why not just run the startup code itself? Well you can do that (With some caveats).

For example, we could change our startmeup function to look like so :

Then we can change our provider line to “useValue” instead of “useFactory”

The main problem you run into with this method is that it’s much harder to use dependencies. We’ll talk about that a little later on. For now, just know you can do either but there are certainly pros and cons for each. Typically I find factories provide me the most versatility.

Inline Methods

It’s obviously worth noting that you don’t need to create an entirely new function variable/object, and you can instead do it all inline.

For the useValue route, you can use :

To do the same thing with factories does look a little messier because you need to return a method that returns a method… So the nesting can look a bit extreme but in general it looks like :

Using Dependencies

It’s possible, but unlikely, that your startup method can run on it’s own with no dependencies. But it’s probably a whole lot more likely that you are going to require either outside services of your own, or Angular’s own helper services. HttpClient for example.

You can inject these into your startup factories. Note that you cannot (easily) inject dependencies when using useValue. Your application won’t blow up, but your dependency will be undefined. There are ways around this but it’s the primary reason to stick with useFactory.

As an example of using dependencies, I can rewrite my startup factory like so :

And I can modify my provider line adding in the “deps” field :

This allows Angular’s built in DI to inject in HttpClient to my startup method which is extremely handy!

Calling Startup Methods Of Services

So, exporting functions all over the place is sort of rough. And it’s pretty likely that we want to bootstrap an actual service (Maybe to reach out and grab configuration values etc). To do that, we can create a class that holds our startmeup factory. We also need to mark it as Injectable.

When adding our provider line, we now instead set our dependency to be the StartupClass (The additional dependency of HttpClient will be resolved behind the scenes when requesting the StartupClass). We still call useFactory as we still have to tell it which particular method we want to run on startup.

Note that our method is actually still returning a function itself. This can be a bit off putting to read in this way so we can change it to instead simply run it’s startup calls :

And then modify the provider line to instead create a factory in of itself :

Notice the additional () to create a method within the useFactory line.

Using Promises

A pretty common scenario for startup methods is reaching for configuration values. That could be from a file, local storage, a cookie etc. And it’s highly possible that these methods are async in nature. As an example below, I’ve modified my startup method to read a settings file.

Note that the await promise line is simply to make it “seem” like it’s taking a long time to complete it’s job. e.g. It’s a slow startup task. In a real world example this wouldn’t be there.

Let’s also go to our main app component and write an NgOnInit method that simple writes to the console log.

Now let’s pause for a second and think. If we run our app right now, what will be written to the console first? The “Configuration loaded” message or the “On Init” message. Well logic would tell us that surely our message that our configuration loaded will run first because we’ve told Angular that the startmeup method should be loaded before everything else.

Well that is wrong.

The problem is that the http get method returns an observable to tell us when it’s complete. And we aren’t waiting for that to finish at all.

The general pattern is to use promises and return that promise to the APP_INITIALIZER. So as an example :

Here we are returning a promise from our method. The App Initializer will actually wait until this promise is resolved before continuing on. If we refresh our page now, we will notice that not only does the “On Init” message come after the “Configuration loaded” message. But the page itself is blank for 5 seconds (Because of our fake sleep to emulate a long http call) because all progress is halted until startup is complete.

This may sound bogus to halt an application like this. But the general idea is that the “majority” of work from your Angular application would not actually be able to take place until the startup method is resolved. For example if you are using telemetry like New Relic, Raygun, Application Insights etc. You really should have the token loaded and App Insights running before attempting to do other work. Otherwise if your application crashes, there is now a race condition as to whether you have all the necessary information to log the error or not.

Usage Outside Of Single Page Apps

As we saw above, the use of APP_INITIALIZER essentially halts the loading of a page until complete. In a true Single Page App (SPA), this is fine because it’s only really going to happen once on the initial load. If you are making use of Angular’s router for instance, then the App Initializer won’t be called again until a proper browser refresh occurs.

Obviously this isn’t the case if you are doing full page reloads. Every page load will re-load the angular app, and therefore kick off the startup process again. Be wary of using the APP_INITIALIZER token in these situations as it can severely slow down your application on every single page load.

I get this little error almost daily when working in Angular (Particularly in VS Code).

The first time I got the issue, it drove me mad as I was copy and pasting code from another file where it was working just fine, yet in my new code file everything was blowing up.

As it turns out, NodeJS has it’s own version of “EventEmitter” that is not generic. When using VS Code or other IDE’s that have auto completion, they will sometimes pick this EventEmitter to import rather than the one from Angular. The way to check is to see what your import statement looks like. It should be coming from @angular/core :

In my (broken) case, it was :

In actuality, there are a couple of EventEmitter objects. For example another half broken example would be :

So just check exactly where you are importing EventEmitter from to get around this pesky error!

When I first picked up Angular many years ago, one of the more frustrating aspects was that on using the router to navigate to another page, the scroll position was kept. This meant you were taken to the new page, but you would be scrolled halfway down the page (Or often right at the bottom if you were filling out a form).

Back then, you had all sorts of crazy fixes involving listening for router events, or maybe even manually scrolling the page. So recently when I ran into the issue on a new project I hoped things had changed. And they have, sort of. I mean, the issue is still there but there is a slightly more elegant fix.

When registering your router module (Typically a new Angular project created using the CLI will have an app-routing.module.ts), you can now edit your import as follows  :

In future versions of Angular, it’s hoped that this will become the default (Certainly there would be far more use cases of scrolling to the top over keeping the same position), but as of writing you still manually need to add the scrollPositionRestoration param.

Note that this was introduced sometime in Angular 6, for earlier versions (Which hopefully you aren’t creating new projects on), you will still need to do the old school subscribe method. To do this, you need to modify your main component (Often your AppComponent) to subscribe to the router event of NavigationEnd and then call scroll.

Again this is required only if you are running a version of Angular before 6!

As part of a recent project, I was asked to limit the type of characters that can be input into a text field. I had a quick search around but every single time I thought I had found a solution, it was some form of using the pattern attribute to simply show if invalid characters had been input, but it didn’t actually stop the user from typing them in the first place.

Now, I know that sometimes this can be a bit of an anti-pattern as a limiting the users input like this can be frustrating when you don’t show any warning or validation message, but there are some valid use cases.

The Directive Code

Below is the actual directive which you can add into your Angular project. In my case, I’m developing in Angular 8, but this should work in any modern Angular version.

A quick rundown of the code :

  • I’m using the selector of “inputrestriction” and I’ve made the input variable itself be called the same. Change as you require.
  • The input string takes a regex pattern to match on *allowed* characters.
  • I’m using the host listener to listen for a key press and deciding to allow it or not.

Usage Examples

We can then crack on with some really simple use cases such as letters only :

Or numbers only :