Check out our Angular Book Series.

How do I access Query Parameters in Angular?

When creating web applications, it is common to add data to a URL that you need to access. For example, one might build an app with a list view that shows a lot of things, such as superheros. Then they have a detail view which shows an expanded detail of a single superhero, such as aquaman.

This post has nothing to do with superheroes. It is all about how to access that item in the URL from an Angular app.

The Setup

I created a default angular application with routing enabled. I created one route, named view1:

const routes: Routes = [
{ path: 'view1/:value', component: View1Component },
{ path: '**', redirectTo: 'view1/default' },
];

The route has a single query param, named value. That is what we'll try to access. The route directs to a new component, which you can create with the Angular CLI:


ng generate component view1

Make sure to replace the main app.component.html with the router outlet:


<router-outlet></router-outlet>

One more thing to do. Open up the view1.component.ts file. We'll need to inject the ActivatedRoute into the component:


constructor(private activatedRoute: ActivatedRoute) { }

You'll also need to import this:


import {ActivatedRoute} from '@angular/router';

You can find the full source here. Let's look at what it takes to access the query param.

Option 1: Params

I set up all these examples in the ngOnInit() method of the View1Component. This is the first:


this.activatedRoute.params.subscribe((params) =>
{
console.log(params.value);
});

The ActivatedRoute has a params Observable. We can subscribe to it, and when it resolves we can access the values. The params object sent to the subscribe function is just an object:

It is a collection of name value pairs and we can access our value using params.value.

Option 2: paramMap

The second option is to access the paramMap. This is also done in the ngOnInit() method against the activatedRoute:


this.activatedRoute.paramMap.subscribe((params ) =>
{
console.log(params['params'].value);
console.log(params.get('value'));
});

paramMap is an observable that resolves to a paramMap. Instead of a generic object, it uses the JavaScript map:

Using a map is a more modern, or ES6, way to handle things instead of using a generic object. The map is better suited for a collection of key value pairs, because it provides an API for accessing values instead of something easily changed.

Option 3: Router Snapshot

The final option I'll show today is to access the snapshot of the activated route. The snapshot mirrors a lot of similar properties to the ActivatedRoute. The main difference is that the snapshot is the route's values at a certain moment in time, whereas the activatedRoute is not. That is why the params, or paramMap, are Observables in the ActivatedRoute, but actual values in the snapshot.

Access the params on the value like this:


console.log(this.activatedRoute.snapshot.params.value);

You'll see something like this:

You can also get at the paramMap, value:


console.log(this.activatedRoute.snapshot.paramMap.get('value'));

You'll see something like this:

Overall, this is similar to using the Observables, except without the Observable part. When accessing the activatedRoute in the ngOnInit, the snapshot should be identical. But, if you need to access something from an unrelated route, or are in the process of switching routes, that is why you'd access the snapshot.

How do you check if a URL variable exists?

When I envisioned this post, I thought I'd write about how to tell if a URL variable exists, but I realized the meat of the post was about finding and accessing the URL variables. If you need to check to see if a value exists, I recommend using the paramMap. For a value that does exist:


if (params.has('value')) {
console.log('it has value');
} else {
console.log('No value');
}

And for a value that won't exist in our demo:


if (params.has('noValue')) {
console.log('it has a novalue');
} else {
console.log('No noValue exists');
}

We use the has() function the params map to check for the existence of the key.

Final Thoughts

Don't forget to grab the code behind this post for runnable samples.

I'm not sure why there are so many ways to get at this data; my preference is to use the paramMap. What about you?

How do I make a TypeScript property that could have multiple types?

I'm working on an app for a client and as with many apps was displaying a list of items. I needed to loop over this list and display items. Every UI framework has some way to do this.

This was an Angular app using TypeScript, so I making use of TypeScript's statically typed nature. My problem was that the objects in this list could be one of two types, let's call those Type1 or Type2. I was running into errors when transpiling the code. I had defined the type like this on the class:


myItems: Type1[];

This code created an array of Type1 arguments. IT wasn't until later that Type2 was added as a possible value in this list.

When updating the code to accommodate for Type2 I realized that sometimes I was receiving errors by accessing Type2 specific properties on a Type1 argument. What was the solution? I used something called Union types. I set up my value like this:


myItems: (Type1 | Type2)[];

This means that myItems can be a mixed array of Type1 and Type2 values.

That works great as long as all properties that you access in Type1 are also in Type2. If a property that you're accessing in one and not the other exists, then you'll get errors--these were the same errors I started with. I solved that issue by adding blank getters to the class definition:


get mySharedProperty(){ return null};

Far from perfect, but functional for my purposes.

Maybe I should have just created an interface and had both Type1 and Type2 extend it?

How do I use a set method to access an conditionally created ViewChild in Angular?

In last week's post I spoke about the problems accessing an Angular ViewChild if it is conditionally created using *ngIf. The solution I proposed there was to use the hidden directive instead of *ngIf. This works, but the caveat is that the child is always created as part of the DOM even if it is not always displayed. I wanted to do another post, providing a different approach

The Setup

I'm going to modify the same application I built last time. It was a simple application created with the Angular CLI and I added one child component. You can get the full code here.

Creating the View

This time, I'm adding a third sample to the app.component.html template:


<button (click)="child3Hidden = !child3Hidden">Toggle Sample 3 Visibility</button>
<br/>
Value Passed into Child: <input type="text" (keyup)="onSample3Change($event)" />
<br/>
<app-view1 #child3 *ngIf="!child3Hidden" ></app-view1>

It uses a value, child3Hidden, to toggle the visibility of the child. Create that in app.component.ts:


child3Hidden = true;

There is an input which is used to change the input value for our app-view1 component:


onSample3Change(event) {
this.child3.value = event.currentTarget.value;
}

This just takes the text input from the AppComponent view and passes it to the ViewChildReference. This is all a similar setup to what we've seen before.

The Problem

Since this ViewChild is conditionally created with *ngIf we cannot access it inside the ngOnInit() and will get an error. The ngOnInit() is like this:


ngOnInit() {
console.log(this.child3);
}

You'll see something like this:

Just an error because the default state of the ViewChild is undefined.

A Solution

Instead of trying to access the ViewChild inside of ngOnInit() we can define the child using get and set methods, like this:


@ViewChild('child3')
set child3(value: View1Component) {
this._child3 = value;
console.log(this.child3);
}
get child3(): View1Component {
return this._child3;
}

Whatever code we want to run in ngOnInit() can be run in the set method, which will get toggled every time the child is created or destroyed. I clicked the button a bunch of times to show you the output:

It is an alternate solution, which works pretty well. The trick part is that whenever you access the ViewChild you'll have to do an undefined check with this approach, something you would not have to do if it were hidden.

Get can get the full code here.

How to Access a Conditionally Created @ViewChild in Angular ngOnInit?

I've been working on an application using Dragula for drag and drop, and dom-autoscroller for scrolling while dragging.

To work, the autoscroller library needs access to the ViewChild, usually set up in ngOnInit. My problem was that we were using *ngIf to hide the scrollable container until things were added to it. As such, the ViewChild was not defined at the time that ngOnInit() ran. This post will explain the problem, and how we solved it.

The Setup

To demonstrate the problem, and our solution, I created a default project with the Angular CLI and added a single component, view1.

The view1 component accepts a single input:


@Input()
value = `default value`;

And the HTML template outputs the value:

view1 works with {{value}}

It is a simple setup. You can get the full code at the Github Repo for my Blog samples.

The Problem

In the app.component.html, add the view child:


<button (click)="child1Hidden = !child1Hidden">Toggle Sample 1 Visibility</button>
<br/>
Value Passed into Child: <input type="text" (keyup)="onSample1Change($event)" />
<br/>
<app-view1 #child1 *ngIf="!child1Hidden" ></app-view1>

The child is hidden based on the child1Hidden value, so create that in the app.component.ts:


child1Hidden = true;

I use a method to update the component's input value. Create as a ViewChild:


@ViewChild('child1') child1: View1Component;

And add the method:


onSample1Change(event) {
this.child1.value = event.currentTarget.value;
}

Note: I know this might be better implemented using HTML properties to update the value, but not all ViewChild interactions are that simple.

Inside the component class, I also want to implement OnInit interface:


export class AppComponent implements OnInit {

And add the ngOnInit() method associated with the interface:


ngOnInit() {
console.log(this.child1);
}

Because the child is hidden by default, this.child1 will be undefined at the time ngOnInit() is run:

Changing the text value before making the child visible will also return errors because our code is accessing an undefined ViewChild reference:

But, once you enable the underlying component:

We are good to go.

The question remains, how do we handle initialization code for that component? I have two solutions, one I'll cover in this post and the second in the next.

Use Hidden

We can replace the *ngIf with the hidden attribute to make this work. Modify our template code:


<button (click)="child2Hidden = !child2Hidden">Toggle Sample 2 Visibility</button>
<br/>
Value Passed into Child: <input type="text" (keyup)="onSample2Change($event)" />
<br/>
<app-view1 #child2 [hidden]="child2Hidden" ></app-view1>

This creates a parallel, similar implementation. It uses child2Hidden instead of child1Hidden. Define it in the app.component.ts:


child2Hidden = true;

Also add the OnSample2Change() method, which updates the input value of the child:


onSample2Change(event) {
this.child2.value = event.currentTarget.value;
}

Be sure to define child2 as a formal ViewChild:


@ViewChild('child2') child2: View1Component;

And output child2 inside ngOnInit():


console.log(this.child2);

Rerun the app:

There are no errors in the console even though the view is not shown.

The reason this works is that when you conditionally show or hide a component using *ngIf Angular removes, or adds it, to the DOM. So, if the value is false, the ViewChild is undefined because the component does not exist. When we use the hidden directive, the component may be hidden from view, but is still created as part of the DOM.

Final Thoughts

I have mixed feelings about using hidden to get around the problem because I am not convinced that it is a good idea to create every child as part of the DOM if it is not needed or being used at the moment. Next week I'll show you a different approach.

You can get the Get can get the full source code, and a peak at next week's sample.

How to access a Constant in an Angular View Template?

Angular provides a mechanism for sharing instance variables inside a component with that template's view component, but how do you access a constant in a view template? Constants in TypeScript are not created as instance variables on a class, so they are not easily accessible inside the HTML template. This post will show you how.

The Setup

Create a new project with the Angular CLI. You can also get access to the full source code in my Blog Sample Github Repo.

Create the Constant File

Create a file in the root directory named constants.ts. Add in a single constant:


export const MY_TEST_CONSTANT = `Something`;

This is pretty simple.

Load the Constant in the Component

The trick to access the constant's value inside the view template is to copy the Constant value to an instance variable in the component. Open up the app.component.ts on your new project, and add a line like this:


myConstant = MY_TEST_CONSTANT;

You'll also need to import the constant:


import {MY_TEST_CONSTANT} from './Constants';

Update the View Template

Now the View Template can access the constants value. Open up the app.component.html file, ad add something like this:


<strong>Here is your Constant</strong>: {{myConstant}}

You're no longer referencing a global constant, but rather a component instance variable that has the same value as the global constant.

It works:

You can use the myConstant value as part of any Angular element in the HTML template including *ngIf, *ngFor, ngModel, or whatever you need.

Don't forget to check out the full code.

How to spy on a Property with Karma?

When writing unit tests, SpyOn, is used to watch and manipulate a method call, potentially returning your own data. This is used to easily mock external component calls so that your unit test can focus on the class in question without worrying about complications or side affects from external dependencies. I found myself in a situation where I had a class and that class had a read only get() property. I was creating my own Angular service wrapper for the Dragula drag and drop library. I was exposing some drop and remove listeners get methods.

I wanted to control the results returned from that get method. This was not a situation where I could set the underlying value because there was no set method. But, spyOn would not work because a get() method is viewed as a property, not a method. The class code was conceptually like this:


export class MyClass {

constructor(private dragula: DragulaService){
}

get dropListener(){
return this.dragula.drop('myDragulaGroup');
}
}

My code was using Angular, so the DragulaService was injected into this component, and the dropListener was exposed via a get.

For the purposes of unit testing, I want complete control over that drop listener Observable. Thankfully, spyOnProperties would give me that control.

The unit test would be a bit like this:


it("Should spy on Observable", () =>
{
const myClassInstance = new MyClass();

let dropObserver: Observable<any>;
const dropObservable: Observable<any> = Observable.create( ( ObserverArg: Observer<any>) => {
dropObserver= ObserverArg;
}

mySpy = spyOnProperty(myClassInstance, 'dropListener', 'get').and.returnValue(dropObservable);

I'm gonna take a quick break to explain spyOnProperty. It takes three parameters:

  • Class: The class instance that contains the property you want to watch.
  • Property: The name of the property being watched.
  • Accessor: The Access Type of the method being watched, in this case get.

Note that we are storing the results of the spyOnProperty in the mySpy variable. This is optional when using spyOn, but for spyOnProperty it is required. The unit test could would continue:


const val = myClassInstance.dropListener;

All that line does is access the dropListener property inside the class, which should trigger the spy. Now we can test against the access:


expect(mySpy ).toHaveBeenCalled();
});

In a more advanced unit test, we could subscribe to the dropListener inside the test, and use dropObserver.next() to trigger the result handler in an async block.

Can I create a Provider in Angular without listing it in the provider array?

This was something new I just discovered. You can create an Angular provider, as a singleton and do not have to list it in the provider array. This post will show you how.

The setup

To set up this project, I used the Angular CLI to create a new project. Then I created two services: ServiceOneService and ServiceTwoService. I also created two views: view1 and views2. You can find the code behind this project in this blog's GitHub repo.

Modify the main app.component.html template to include the two views:


<app-view1></app-view1>
<br/>
<app-view1></app-view1>

Create the services

Service1 should look something like this:


import { Injectable } from '@angular/core';
@Injectable()
export class ServiceOneService {
text = `from service one`;
constructor() { }
}

It is created as injectable, and has a single property. Open the app.module add this as a provider:


providers: [
ServiceOneService
],

Service2 should look something like this:


import { Injectable } from '@angular/core';
@Injectable({
providedIn: 'root'
})
export class ServiceTwoService {
text = `from service two`;
constructor() { }
}

The service looks almost identical, even having the same text property on it. The big difference is in the injectable metadata, we added a providedIn: 'root'. This is the trick to creating a provider without defining it as a provider. means that the first time the service is injected, Angular will create the Singleton just as if it were set up as an explicit provider.

The Views

Open up the TypeScript file for view1 and view2 and load the services:


constructor(public service1: ServiceOneService, public service2: ServiceTwoService) { }

Open up the HTML component for each view and paste this in there:


From Service 1, set up as traditional provider:
<input type="text" [(ngModel)]="service1.text" >
<Br/><Br/>
From Service 2, using providedIn = root:
<input type="text" [(ngModel)]="service2.text">

This just puts an input on the screen, one binding to the service1.text, and the other binding to service2.text.

Since we're using ngModel don't forget to load the import the FormsModule into the appModule:


imports: [
BrowserModule,
FormsModule
],

Run the Code

Now run the code and load it in a browser. When you type in the service 1 input in one component, the input in the other component should also change:

This is what is normal and we're used to because we set up Service1 as a provider and the single instance should be shared between the two components.

Now try to type in the service 2 input. The values also change:

This surprised me, since Service2 is not set up as a provider. However, the `providedIn` metadata tells Angular to create Service2 as a service. It works like magic.

Get The Full Source for this Sample.

Happy New Year

The new year is often a time to reflect back and look forward. This post is just that.

The Work

I don't usually talk about client specifics, but one project has given me more of a public profile than I'm used to. in 2018 I started working with Disney Streaming Services, and I have started contributing posts to the Disney Streaming Blog. The first post is already up, and I talk about using the Angular CLI to create and combine multiple applications.

The editing process for this blog is a lot tougher than the editing process for my own blog or this newsletter and I feel like some of my voice was stripped out. I'm doing my best to make sure that does not happen with the second post, which is starting the edit phase.

The Learn With Book Series

I had two updates to the Learn With Angular books in 2018, one for Angular 6 and one for Angular 7. The Angular 7 updated represented a major re-write, because I updated the text to use the Angular CLI instead of my home-grown tools. When I started the series, the Angular CLI wasn't a thing, but today it is the best way to write an Angular application.

The bulk of the new content is in the bonus book. I added a chapter on using Redux with Angular, and covered Augury. This year my hope is to expand the series to include a version that uses the material library instead of bootstrap. I'd also love to create a React version of the books. I also want to dig deeper into the rxjs library which underpins both Angular and React. We'll see what time allows.

The Blog

My goal is to write at least one new blog post a week, and I've been at it since October 2015. I had a short reprieve last summer for personal reasons--see below--but still managed to write 53 posts in 2018. I expect to continue writing throughout 2019.

A lot of the stuff I write is down in the nitty gritty of writing code, but I have some plans to write some more philosophical thoughts on the development process. First up is a post about naming conventions all throughout the stack. I hope to have that ready for the next newsletter but have a few other writing commitments in front of it.

Every year I tell myself my blog needs a serious redesign and update. I finally started work on it. My first step was to upgrade to the latest version of BlogCFC, which I have working locally. I created my own branch of the BlogCFC code base and merged in a lot of the custom changes I have made throughout the years. I expect this to be an ongoing process throughout the first quarter of this year.

Personal Stuff

On a sad note, I buried my father last summer. I'm fine about 90% of the time, but some days it hits me harder than others. My dad lived a good life, and is sorely missed by myself, my mother, and my 3 siblings. I miss him.

On a lighter note, in 2019 I'll be celebrating my 10th wedding anniversary. We're planning a big party--just like a wedding except this time we can invite the people we want to invite instead of the people we have to invite. It should be fun.

How was your 2018 and what do you plan to do for 2019?

How do I set up a Proxy Server with Angular?

This is an excerpt from my Learn With series on Angular 7, which came out about a month ago. I wrote this up for the DotComIt newsletter, and thought I'd share it here too.

This post details how to use Angular's server side proxy to connect the Angular CLI dev server to access the NodeJS application server without having to worry about cross domain issues. The Angular CLI dev server is not set up to run normal server-side code, like custom NodeJS, ColdFusion, PHP, or Java. Instead the preferred approach is to set up a server-side proxy to redirect your Angular calls to your other remote servers.

The first step is to create a proxy config file. Name the file proxy.conf.js and put it in the root directory of the project, where the angular.json file is located. It should start as an empty file, but let's create a constant:


const PROXY_CONFIG = [{ }]
module.exports = PROXY_CONFIG;

The code also exports the configuration. The PROXY_CONFIG is an array of objects, although for our case we'll just have a single object. First, add a context:


context: [ "/nodejs" ],

The context value says "Whenever a URL comes in that contains `/nodejs`, we'll redirect it elsewhere. Exactly where you want to redirect it depends on your local configuration. Add a target property:


target: "http://127.0.0.1:8080/",

In the case of NodeJS, we're redirecting the request to a different port on localhost.

Set the secure to false:


secure: false,

In local dev environments I never set up HTTPS or use secure URLs like I would in a production environment. There are a few other values that may be needed or not depending on your local setup. I'll go over them here for completeness.

First, you can have the proxy to rewrite the path:


pathRewrite: { "^/nodejs": "" },

You'll only need a path rewrite if you need to modify the URL. For example, if your API will call '/nodejs/authenticate', but your actual service is set to '/authenticate', then this will allow you to direct your service call to the proper code.

Another value to be aware of is changeOrigin:


changeOrigin: true

You'll only need to use the changeOrigin value if you are setting up a local alias for your NodeJS sample. For example, if your NodeJS server is set to listen to requests on 'local.nodejs.learn-with.com' then this will tell the proxy it is okay to rewrite domain from localhost to 'local.nodejs.learn-with.com'.

The last value I want you to be aware of is the debug:


logLevel: "debug",

When you set this property, the console will give you a lot of details of how the proxy is working and rewriting URLs. It can be handy when you need to debug things.

Final Thoughts

I hope you're doing well in this holiday season.

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

How do I prevent a Browser from opening up when I run Angular unit tests?

When you run unit tests using the Angular CLI's ng test command you'll often see a browser open up. Sometimes this is useful if you want to debug the unit tests in the browser, however since I have moved the bulk of my unit test debugging to IntelliJ, this is just a minor annoyance.

You can shut it off. Open up the Karma.conf.js file in the src folder of your Angular CLI project. Find this line:


browsers: ['Chrome'],

This tells Karma to open Chrome to run the tests. But, there is another option:


browsers: ['ChromeHeadless'],

Rerun your tests and you'll find that no browser opens up.

I love it when things are easy.

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 5.9.2.002.