Check out our Angular Book Series.

My Angular 6 Books are Out

Aside from being swamped with client work, I've just updated the Learn With series for Angular 6.

This is a relatively minor update as there were not a lot of changes between Angular 5 and 6, but if you want to find out the information on the latest version that is the best way to get it.

Right now I'm working on a series of longer articles about using Redux and Angular. They should be out soon.

What are Route Guards in Angular?

When you build an Angular application, you're probably going to use a router. The router is a library that allows you to change the URL of the application, and with that URL change to load new components. How do you protect parts of your application from being accessed by users who are not authorized? You use a Route Guard.

What is a Route Guard?

A Route Guard is code that Angular will execute when processing the route. I have been using one to determine whether a user should have access to the route or not. However, they can be used for any purpose. There are a handful of different hooks that can be used:

  • CanActivate to mediate navigation to a route. This is the one I'll demonstrate today.
  • CanActivateChild to mediate navigation to a child route.
  • CanDeactivate to mediate navigation away from the current route.
  • Resolve to perform route data retrieval before route activation.
  • CanLoad to mediate navigation to a feature module loaded asynchronously.

That list is copied from the documentation, because I don't think a lot of elaboration is needed.

Using CanActivate

I'm going to use modified code from my latest book on Angular 6, which you should get if you want a beginner's introduction to Angular.

The first step is to create a Service:

import { Injectable } from '@angular/core';
import { CanActivate, Router } from '@angular/router';

export class AuthGuard implements CanActivate {
constructor() {}
canActivate() {
return userHasLoggedIn

The guard is marked as Injectable and implements the CanActivate method. I greatly simplified the algorithm for determining whether a user has logged in or not, but it can be as complex as you need it. I'm just returning a Boolean value. If the user has logged in--via the userHasLoggedIn value, then the user can activate this route and the canActviate() method returns true. If the user has not logged in, then canActivate() returns false and Angular will know now to load the route.

Since this is a service, load it in your module. In the LearnWith books, I set up a module strictly for routing purposes, so it looks something like this:

import {AuthGuard} from "./auth-guard.service";
imports: [ RouterModule.forRoot(ROUTES) ],
exports: [ RouterModule ],
providers: [AuthGuard],

A constant named ROUTES defines the application's roots:

const ROUTES : Routes = [
{ path: 'login', component: LoginComponent },
{ path: 'GotIn', component: MainApplicationComponent, canActivate: [AuthGuard] },

The object which defines the router has a canActivate property and uses the AuthGuard class as it's value. So, when the user purposely tries to load the GotIn route, the canActivate() method inside the AuthGuard class will execute and determine whether the user can view this route based on their logged in status.

Route Guards a powerful and something to learn if you care about the security if your application.

Be sure to pick up my full book series on Angular 6.

Using Angular, RXJS, and SystemJS

just updated DotComIt's build scripts for building Angular 6 applications. I wrote these before the AngularCLI was king of the heap and keep these around because I haven't had time to update my LearnWith series, which contains an introduction to Angular.

Anyway, I copied my Angular5 scripts, updated the package.json to a bunch of new versions, build the sample app, and then started getting errors from the application:

Error: Unexpected token <

My local dev server has directory browsing turned on, so instead of loading the actual files behind rxjs it was trying to load the directory listing. That won't work. I also saw this error in my experimentation, which said that '"rxjs/operators" not found'. Supposedly that issue was fixed long before RXJS 6.0.0, but alas I was still seeing it.

The solution was to list all the rxjs directories as a package inside of SystemJS Config:

packages: {
'rxjs/ajax': {main: 'index.js', defaultExtension: 'js' },
'rxjs/operators': {main: 'index.js', defaultExtension: 'js' },
'rxjs/testing': {main: 'index.js', defaultExtension: 'js' },
'rxjs/websocket': {main: 'index.js', defaultExtension: 'js' },
rxjs: { main: 'index.js', defaultExtension: 'js' }

It took me a while to find this solution, and even then I couldn't get it to work until I removed the quotes around the last package definition.

Weird stuff,

How do I test the text of an HTML Element with Jasmine, Karma, and Angular?

I think this should have been simple, but my Google Fu was failing me. I'm working on an Angular app, as I often do, and was writing unit tests to verify that property changes inside a Component's class were reflected inside the view template.

The Component and View

I'm just going to use truncated code here, but the component had a property like this:

export class MyClass{
@Input() buttonText : string = "";

The template had something like this:

<button class="myButton">{{buttonText}}</button>

Change the value on the component, and the view should change. This sort of binding is basic to Angular. How do we test that?

Write the Tests

First, you set up the TestBed:

beforeEach(async(() =>
declarations: [ MyComp ]
fixture = TestBed.createComponent(MyComp);
component = fixture.componentInstance;

This should be pretty standard, and this code is almost copied verbatim from the Angular CLI defaults.

Now your test should do something like this. First set the value on the component

const defaultButtonText = "Something"
component.buttonText = defaultButtonText ;

Now you have to detect the changes to force the view to refresh itself:


Get the HTML Element:

const button = fixture.debugElement.query(By.css('.myButton'));

And check the button's TextContent:

expect(button.nativeElement.textContent.trim()).toBe(defaultButtonText )

You're code should be all set to test.

For completeness, here is the full test:

it('Set Button Text to Something', () =>
const defaultButtonText = "Something"
component.buttonText = defaultButtonText ;
const button = fixture.debugElement.query(By.css('.myButton'));
expect(button.nativeElement.textContent.trim()).toBe(defaultButtonText )

I hope this helps someone.

How do I listen for an Angular Event in TypeScript?

I'm building a custom Angular service for a client project that will create modal and other popups. If certain interaction occurs within the modal, then the modal should dispatch an event and the service needs to close the modal. In Angular you can use an EventEmitter to dispatch the event from the component's class. Create the emitter as a property on the component's class and add the @output metadata:

myEvent : EventEmitter<any> = new EventEmitter();

Then to dispatch the event use the emit method:

this.myEvent.emit('Emitted Value');

That does exactly what I need in the component side. However, to listen for the event, most of the documentation I can find talks about doing so in the HTML template:



Unfortunately, the service cannot add that event handler onto HTML because there is no HTML, so that was a no go for my use case. How do you do it?

After the service creates the component and displays it, it has an instance to that component class. We can introspect into the component class to get access to the emitter, and subscribe to it:

myCompRef.instance.myEvent.subscribe((value) =>
// do something

Under the hood the EventEmitter is a Subject, which is like an Observable.

How to I make my Angular Component Styles global?

An awesome thing about building Angular components is that the styles you specify are 'local' to the component.

In normal HTML development, any style on the page can affect any other style. For example. If I add a style like this:

div {
border:1px solid red;

Every div in the site / application will have a solid red border. Check out a sample here.

If you build an Angular, component, and that style is only included in the application as part of the component, then only that component's div will given a solid color red border.

The reason for this is because Angular creates something they call a Shadow DOM. Under the hood it is some coding magic to conditionally apply styles only to the component in question, not to other components.

However, Angular allows us to change this behavior using something called ViewEncapsulation.

A default Angular component is like this:

selector: 'my-comp',
templateUrl: 'my-comp.component.html',
styles: [`my-comp.component.css`],
encapsulation: ViewEncapsulation.Emulated

The Emulated value means that Angular will simulate a Shadow DOM. This is considered safest because not all browsers support their own shadow DOM trees.

In most cases, I use this approach and leave out the encapsulation attribute. I like to have my styles encapsulated to a single component. But that is not required. There are two other options:

selector: 'my-comp',
templateUrl: 'my-comp.component.html',
styles: [`my-comp.component.css`],
encapsulation: ViewEncapsulation.Native

The Native property tells Angular to use the browsers Shadow DOM. In this case, styles are encapsulated just like they would be in the emulated approach. So, any styles in the my-com-componment.css file will affect all HTML elements globally.

To turn off style encapsulation complete, use the None value from the ViewEncapsulationclass:

selector: 'my-comp',
templateUrl: 'my-comp.component.html',
styles: [`my-comp.component.css`],
encapsulation: ViewEncapsulation.None

I'm working on my second super really big Angular application for a client, and it is giving me the opportunity to touch on areas I normally wouldn't.

The Learn With Series now includes Java and PHP

The Learn With series now includes a few new book that talk about integrating with Java or PHP.

Check them out now.

I'm greatly enjoying writing these books, experimenting with different technologies, and taking you all along for the ride.

How do I Fix Uncaught (in promise): Error: StaticInjectorError[] in Angular 5?

I've updated my Learn With Programming Books to Angular 5. Angular changed their versioning structure, so Angular 5 is more like Angular 2.2 than a complete update.

Unfortunately, the upgrade was not seamless and this error drove me insane. Everything I thought I'd fix it, it would crop back up:

ERROR Error: Uncaught (in promise): Error: StaticInjectorError[UserModel]:
NullInjectorError: No provider for UserModel!
Error: NullInjectorError: No provider for UserModel!
at _NullInjector.get (injector.js:31) [angular]
etc.. etc..

The error looked like this:

The underlying cause of this error is that Angular 5 changed how they create providers moving from a reflect based injector to a static injector. This removes the need for the reflect polyfill that is used in Angular applications. Without digging deep into Angular code I can't explain better, all I knew was that I had the error and needed a resolution.

If you search, you'll find a lot of write ups on this, but it was trial and error that solved the issue for me. Here are two things to look at that helped me solve the issue.

Check Your TypeScript Version

Angular 5 requires TypeScript 2.3 or later, so make sure that your build scripts have the proper version installed. I'm using TypeScript 2.4, and your package.json should look something like this:

"typescript": "^2.4.0",

If you're using the Angular CLI this shouldn't be an issue, as it should already have the proper versions set up.

Check Case Sensitivity of Classes and Imports

This is the one that drove me nuts. About half of my development standards come from 'legacy' applications, and the rule of thumb used to be to name class files in proper case, so UserModel.ts instead of usermodel.ts. However, it appears--and I'm not sure why--that Angular has a problem with the mixed case of the class imports. If I was importing two classes from the same directory and setting them up as providers in the main application, I would get this error.

This would cause errors:

import {UserModel} from "../model/UserModel";
import {TaskModel} from "../model/TaskModel";

// other stuff here
providers : [ UserModel, TaskModel]

This would not:

import {UserModel} from "../model/usermodel";
import {TaskModel} from "../model/taskmodel";

// other stuff here
providers : [ UserModel, TaskModel]

Even if I changed nothing with the actual import files. By putting all the class imports in lower case, I was able to avoid the issue.

That was until I set up unit tests using karma-typescript. Karma TypeScript spit up on the imports with incorrect case. I ended up putting the file names in all lower case so they would be fine with my Angular Build Scripts and with the Karma TypeScript tests.

Final Thoughts

I thought the upgrade, and book update, would be a couple of days, but took me a full week. So, go check out my Angular 5 books, or at least get on my mailing list using the form below.

Keep up to date by reading DotComIt's Monthly Technical Newsletter

Testing a Bootstrap Popup with Angular - Part 2

This is the second half of my article on testing a Bootstrap popup. Before reading this, you should read my post about creating a popup with Angular and Bootstrap, and the one about testing the popup component. This post will focus on testing the code that creates the popup.

Review Code

In my test sample, the code to create the popup is in the app.component.ts file. This is it:

onModalRequest():void {
const modalRef = );

modalRef.result.then((result) =>
}).catch( (result) => {

This is triggered by button click in the view. Create an instance of the modal using the modalService, which is an instance of the NgbModal. It saves that instance in another variable, modalRef. The modalRef.result is a promise, and we can use that to run code whenever the modal is closed or dismissed. The promise then() method represents a successful closure of the modal. The promise catch() method represents a dismissal. Since this is a test app, the close and dismiss methods don't do anything other than log items out to the console, but a real app may save data or update a view.

We're going to write a few tests against this code. The first will just verify that the modal opened. Then we'll open and close the modal, verifying that the result function was called. Then we'll open and dismiss the modal, verifying that the catch function was called.

Write the Tests

I put my tests in a file named app.component.test.ts. As always, we'll start with the imports. These are the Angular testing imports and the ng-bootstrap imports:

import {async, TestBed,ComponentFixture} from '@angular/core/testing';
import {NgbModal, NgbModalRef } from "@ng-bootstrap/ng-bootstrap";

Now, load our custom components:

import {AppComponent} from "../../../../../src/com/dotComIt/learnWith/main/app.component";
import {PopupComponent} from "../../../../../src/com/dotComIt/learnWith/views/popup/popup.component";

We import the AppComponent, which contains the code we'll be testing and the PopupComponent which contains the code we'll be testing. Now, create a describe function to create the set of unit tests:

describe('AppComponent', function () {

Next, create a bunch of variables inside the describe:

let fixture: ComponentFixture<AppComponent>;
let appComponent: AppComponent;
let modalService: NgbModal;
let modalRef: NgbModalRef;

The ComponentFixture is used to create an instance of a component so you can access all properties, methods, and DOM elements of its HTML template. The appComponent is an instance of the component's class. The modalService and modalRef relate to the popup window that will be created.

Here is a beforeEach():

beforeEach(async(() =>
TestBed.compileComponents().then(() => {
modalService = TestBed.get(NgbModal);
modalRef =;
fixture = TestBed.createComponent(AppComponent);
appComponent = fixture.componentInstance;
spyOn(modalService, "open").and.returnValue(modalRef);

It compiles the components on the TestBed. Remember the TestBed was configured in a base.test.ts file, which our scripts know to compile first. After the components are compiled, we get the modalService and create a modalRef by opening the component. The fixture instance of the AppComponent is stored as is its componentInstance.

Finally the beforeEach() creates two spyOn() methods. It looks at the open method of the modalService, and tells it to return the modalRef as a specific value. Then it spys on the console.log() method. Normally I would try to avoid spying on this, but since no real functionality exists inside our app this is the best way to determine if the close or dismiss methods will run on the modal popup.

Let's start off with an easy test, to see that the modal opened:

it('Modal Opened', function () {

This is pretty self-explanatory. It calls the appComponent's onModalRequest() creates the modal, and checks to see that the open method had been called, insinuating that the modal had been created.

Let's create the modal, then close it:

it('Modal Opened, then Closed', (done : DoneFn) =>
fixture.whenStable().then(() => {
fixture.whenStable().then(() => {

First thing you notice is that a done() function is passed into the test function. This is a function that tells Jasmine to run the code asynchronously. This is a special Jasmine construct, and is different than the async or fakeAsync test beds which are Angular constructs. The Angular constructs have all sorts of issues if you use any sort of timer under the hood, and gave me lots of problems when I was writing the test code for the learn with app. This approach avoids those issues.

Next, the onModalRequest() method is called on the appComponent. Then we access the fixture to detectChanges(). This tells the component to process a digest cycle. It will redraw whatever needs redrawing. In our case, it waits for the modal to actually be created and opened. Then we wait until the fixture is stable using the whenStable() function. This means the modal was created and it is all good to continue. The whenStable() method returns a promise, and we execute the success function on it. Inside the success function we call a close() method on the modalRef value. We do not need to call the detectChanges() again, but we do need to wait until code is stable before running our assertion. The assertion excepts that console.log() will have been called with the value "closed". This is the hard coded result value inside the main app component code. Finally it calls the done() function to tell Jasmine that we are done running async code. This completes the test

To test the dismiss function, we use a similar approach, but I needed an extra level of waiting until the component fixture was stable before I could check for the dismiss function to have been called:

it('Modal Opened, then dismissed', (done : DoneFn) =>
fixture.whenStable().then(() => {
fixture.whenStable().then(() => {
fixture.whenStable().then(() => {

The code opens the modal with appcomponent.onModalRequest(). Then it calls fixture.detectChanges() to watch for the DOM changes. Then it uses whenStable() to make sure the modal opened. When it is open, it is dismissed. Then it waits until it's stable twice before running the assertion. The assertion checks that the console.log() method was called with the 'cancelling' string. Then it calls the done() function, finishing off this method.

Run it:

Gulp test

And you'll see results like this:

Final Thoughts

When researching how to test a popup with Bootstrap and Angular 4 I found a lot of conflicting information. But, I hobbled through it and found this approach which seemed to work well for me. I wrote a full 70 pages on Unit Testing in the bonus book to my Angular 4 series. Get it now!

Keep up to date by reading DotComIt's Monthly Technical Newsletter

Testing a Bootstrap Popup with Angular - Part 1

Last week's post showed you how to create a popup using Angular 4 and ng-bootstrap. This week, I'll show you how to test it. This post covers testing the popup component. Next week I'll test creating the popup.

Get a Testing Framework

You'll need a testing framework. I have my own scripts based on Karma, Jasmine, and karma-typescript. I write about this in full details in the companion book to my Angular 4 book series. You could also use the Angular CLI or scripts of your own choosing. Specifics of the setup is beyond the scope of this article, because I want to focus on the tesing technique.

Configure the Test Module

Angular includes a testing construct called TestBed. This is a module created for testing other modules and is considered the foundation of all Angular tests. We're going to create a base.test.ts file to set up the TestBed to parallel the main application. This will parallel the main application from our source app.

It doesn't matter where you create the base.test.ts file as long as it is loaded by your testing code, and your apps main module is ignored. I place it in the root of a testing directory. When the app runs in a browser, the index loads a shim library and a ZoneJS library that are required by Angular. But the tests are not run in a browser, so we need to import these scripts manually, like this:

import "core-js"
import "zone.js/dist/zone";
import "zone.js/dist/long-stack-trace-zone";
import "zone.js/dist/proxy";
import "zone.js/dist/sync-test";
import "zone.js/dist/jasmine-patch";
import "zone.js/dist/async-test";
import "zone.js/dist/fake-async-test";

This will prevent a lot of confused errors about uncaught reflect-metadata and class decorators. Now we need to import the Angular specific testing modules:

import { TestBed } from "@angular/core/testing";
import { BrowserDynamicTestingModule, platformBrowserDynamicTesting } from "@angular/platform-browser-dynamic/testing";

This imports the TestBed which is the testing module. It also imports BrowserDynamicTestingModule and platformBrowserDynamicTesting. These are used to parallel the platformBrowserDynamic class which loads the initial application.

With these imported we can immediately initialize the TestBed:

TestBed.initTestEnvironment(BrowserDynamicTestingModule, platformBrowserDynamicTesting());

Now import the BrowserModule which is the ng module for the browser, and the NgbModule, which contains the ng-bootstrap libraries:

import { BrowserModule } from '@angular/platform-browser';
import {NgbModule} from '@ng-bootstrap/ng-bootstrap';

Now, import the custom components from our demo:

import { AppComponent } from '../src/com/dotComIt/learnWith/main/app.component';
import { PopupComponent } from '../src/com/dotComIt/learnWith/views/popup/popup.component';

Now, configure the TestBed:

beforeEach(() =>
imports : [BrowserModule, NgbModule.forRoot()],
declarations: [ AppComponent, PopupComponent ]
}).overrideModule(BrowserDynamicTestingModule, {
set: {
entryComponents: [ PopupComponent ]

The first thing to notice is that I put the TestBed configuration in a beforeEach() function. What is beforeEach()? It is a special function that is part of the Jasmine testing framework. The function allows you to run code before the tests are executed. We use it to create and configure the testing module which will be used by most of our other unit tests. You can have multiple beforeEach() functions if needed, but here we only need one.

The configureTestingModule() accepts a configuration object which sets up imports for other modules and declarations for components. This is all like the @NgModule metadata in our main application. The configureTestingModule() does not support entryComponents, unfortunately. We used the entryComponents metadata to set up the component that ng-bootstrap will use to create the modal.

Thankfully there is a workaround. We daisy chain an overrideModule() method after the configureTestingModule is created to add the entryComponents metadata.

That's all we need in the base.test.ts file. Notice there is no formal export of a class. It isn't needed, since no other classes will use this explicitly. Be sure this file is compiled into your tests before your other code to avoid compile errors.

Test the Popup

Now, we're going to test the PopupComponent. There are two methods that we care to test:

onDismiss(reason : String):void {
onClose():void {

The first is the onDismiss() method, which will occur if the user cancels the popup. It means all changes are cancelled. The second method is the onClose() method and it occurs if the user formally closes the popup with the close button.

Create a file named popup.componment.test.ts. Start with imports:

import {async, TestBed} from '@angular/core/testing';
import {NgbModal, NgbModalRef, NgbActiveModal} from "@ng-bootstrap/ng-bootstrap";
import {PopupComponent} from "../../../../../../src/com/dotComIt/learnWith/views/popup/popup.component";

It imports the async and TestBed modules. The async import is used to run a beforeEach() or it() test inside an async test zone that mocks the mechanics of asynchronous processing. Then some modal specific classes are imported from ng-bootstrap. Finally our custom PopupComponent is loaded.

Now, create a describe function:

describe('popupcomponent', function () {

The describe() function is a Jasmine function that defines a test suite, which is a collection of related tests. The function takes two arguments. The first argument is a string that is the name of the test suite, in this case 'Sample Tests'. The second argument is a function, which runs the tests. You can embed a describe() function inside other describe() functions if you feel it is relevant to your testing.

Create two variables inside the describe() block:

let comp: PopupComponent;
let activeModal : NgbActiveModal;

We'll define these values in a beforeEach() block and reuse them in individual tests. Look at the beforeEach() next:

beforeEach(async(() =>
TestBed.compileComponents().then(() => {
let modalService : NgbModal = TestBed.get(NgbModal);
const modalRef : NgbModalRef =;
comp = modalRef.componentInstance;
activeModal = comp.activeModal;

We compile the components on the TestBed. This returns a promise, which we use to get access to the global variables our tests will need. First it creates a local instance of the modalService. It uses that modalService to open the popup and create the modalRef variable. The component instance is saved off the modalRef. And the activeModal value is pulled out of the component for easy access.

The first test:

it('should create component', () =>
expect(comp).toBeDefined() );

The it() function defines the test. It has two arguments, and the first is the descriptive name of the test. If it fails, you can use this name to determine which test actually failed. The second argument is a function that performs the test.

The test is written to be easily parsable:


This is called an assertion. We expect the component to be defined. This will return true if the component exists, or false if the component does not exist. This is often an easy test to run to make sure you have your configuration set up correctly.

Let's write a test for the onDismiss() method:

it('Call onDismiss()', () =>
spyOn(activeModal, 'dismiss');
comp.onDismiss('Some Reason');
expect(activeModal.dismiss).toHaveBeenCalledWith('Some Reason');

This test uses a new command, spyOn(). The spyOn() method is used to watch an object for a method call. You can use this in tests to intercept the method and return specific values. Alternatively, you could use it to verify that a certain method was called. The spyOn() is looking at the activeModal as the first argument, and the dismiss method as the second argument. Then the onDismiss() method is called on the component. Two tests follow. One to make sure that the dismiss() function was called. And the second to make sure it was called with a specific argument, 'Some Reason'.

The test of the onClose() method operates using a similar fashion:

it('Call onClose()', () =>
spyOn(activeModal, 'close');

Instead of spying on the dismiss method of the active modal we spy on the close method. And that is the method we check in the two assertions.

Try this out by running your tests. If you use my seed, use this:

Gulp test

And you'll see something like this:

Final Thoughts

This concludes this article, but I have another one coming out next week. It will examine the code I use to test the component that creates the popup.

If you want all this information and more, get my the bonus book to my Angular 4 book series. It shows you how to create an app from scratch, and covers Angular CLI, unit testing, debugging techniques, and how to build your own project seed.

Keep up to date by reading DotComIt's Monthly Technical Newsletter

More Entries

All Content Copyright 2005, 2006, 2007, 2008, 2009 Jeffry Houser. May not be reused without permission
BlogCFC was created by Raymond Camden. This blog is running version