As part of a recent build of mine, I added the website to Google Webmaster Tools. Now, among other things, these tools provide insight into how Google sees your website functioning, and also gives feedback on any issues it found while crawling your pages.

A big focus for Google in the past 10 years, has been how websites function on mobile. Do they load in a reasonable time? Does the javascript require a huge amount of resources that makes your phone too hot to handle? And more recently, does your website function in a way that’s easy to use on a mobile touch screen?

That last point is frankly, a little subjective, but it’s one that Google is taking a keen eye on. And when you fail their test, you get a rather vague message of “Clickable elements too close together”. I actually searched the web for any tool that could actually pinpoint what exactly on my website was causing the issue, but to no avail. So unfortunately, there is a bit of trial and error involved. But you can speed up that trial and error by knowing where to look.

Element Size And Margin – The Key Culprits

Almost universally, you’re going to run into this problem when a clickable element is either too small, or it’s too close to another element that is also clickable. An example I will show you shortly was that I had a button that opened the side menu right up against a link that takes you back to the homepage. The button itself was too small, but additionally, the fact that there was no gap between the two items was also a mobile usability problem.

I hunted around for the exact numbers that I should be aiming for, and there seemed to be a little bit of a consensus on the following :

  • Any element that is clickable (That is not a text link) should be at least 48x48px (e.g. Buttons, images, SVGs etc)
  • Any element that is clickable should have at least 8px margin on all sides from any other clickable element

These are your starting points, so if you can look at your website right now and immediately identify problems with the above, then you are good to go! Start making changes and testing those updates using the steps below.

Finding Clickable Elements

One way to help you diagnose any mobile element problem is to add an outline to any element that is clickable. For that, you can use the following CSS :

a, input, button, svg {
    outline: 1px solid red;
}

Note that I’ve put SVG in there for my own needs (Since I have clickable SVG’s on my site), but should you not, then you can remove it. By the same token, if you have clickable elements that you want to check if they overlap, then be sure to add them.

You can either add this CSS in development *or* you can use something like Chrome Dev Tools to see things on the fly.

In my particular case, I ended up with a view like this :

Clearly now I can see that these elements are too close together and are actually overlapping somewhat. Using this visual tool, we can easily identify elements that don’t have the appropriate margin, and easily rectify them.

Every Element Is Tested

Something that caught me out is that elements I thought would be “invisible” to Google were in fact causing problems. This included a slide out menu that is only shown on mobile, and an iframe to another site. I figured that in the iframe’s case, I would not be penalised since I didn’t even think Google would bother loading the iframe in any testing tool. I was wrong, very very wrong!

This may be obvious, but just in case it isn’t, don’t assume something is not relevant to what Google is testing. If it’s on the page, or it’s reachable in some way, it could be causing the error.

Testing Changes

The easiest way to test if your changes have fixed the problem is to go to Google’s official tool at : https://search.google.com/test/mobile-friendly. I’ll be the first to admit that this tool can be a bit finicky and it sometimes takes a few changes to finally get your website the green light. Elements that I thought would be causing issues, actually were fine, and it was other inconspicious items that were doing all the damage. The trick is, just keep adding margins and testing your changes until you get it right.

If you are having to make large scale UI changes that you aren’t happy with, you still want to get to the point where Google is liking your page, and then you can start rolling back changes one by one, to see which changes actually had an affect. Again, it’s painful because Google will not tell you exactly which elements are causing problems, so trial and error is really your only way.

Some code I was working on required me to delve into what the differences between Empty, Never and Of were in RxJS. Specifically, I had a method that returned an observable purely so that I could “wait” or “subscribe” for it to finish (e.g. It did not return an actual result). Imagine something like this :

myMethod() : Observable<object> {
  //Go and do something
  return this.http.post('/myurl', null);
}

In reality, I’m not interested in the result, but I am interested in waiting until the call is complete. Therefore, I may have code such as :

this.myMethod().subscribe(x => {
  //Continue something here. 
})

Where I ran into issues, was what if I wanted to short circuit myMethod()? What if I had a cache or sorts, or logic that determined I didn’t need to call the API at all? What should I return to still fire my continuation method? The results were interesting..

Using EMPTY

RxJS 6+ has a special type called “EMPTY” that acts as an empty observable. When I first used this, my code compiled fine but while testing, I noticed that my continuation never fired.

The documentation for EMPTY (And it’s deprecated sibling empty()) state :

Creates an Observable that emits no items to the Observer and immediately emits a complete notification.

It’s important here to note that while the observer is completed, it emits nothing on it’s way to doing so. For example :

EMPTY.subscribe(x => {
  console.log('Empty Emit'); //This never fires. 
}, 
null, 
() => {
  console.log('Empty Complete'); //This does. 
});

What this means is that if you are using EMPTY to short circuit your code, but your code subscribes to the returned observable, EMPTY will in fact not work.

Using NEVER

While, given the name, I didn’t have high hopes that using NEVER would solve my problem, I did want to see how it functions. So using this code :

NEVER.subscribe(x => {
  console.log('Never Emit'); //This never fires. 
}, 
null, 
() => {
  console.log('Never Complete'); //This never fires. 
});

NEVER well… It never fires anything. It doesn’t emit anything nor does it complete the observable. This may be useful in very limited cases where you need to return a value, but you don’t want subscribers to act on it *or* for anyone to act on the observable completion.

Using Of

That brought me to using Of. I had used this before but slowly drifted to using EMPTY when in fact, using our example :

of({}).subscribe(x => {
  console.log('Of Emit'); //This fires. 
}, 
null, 
() => {
  console.log('Of Complete'); //This fires. 
});

This works perfect! Not only does the emit fire, but the observable also completes. I would like to point out that in this example, I have used of({}), if you instead use Of() with no value, then you will instead complete the observable but not emit a value (Similar to EMPTY). Of simply wraps a static value in an observable and emits immediately, allowing you to short-circuit otherwise asynchronous methods.

Which One To Use?

If you want to return a value and call all subscribers, then you must use Of(value).  If you want to return a value and *not* call subscribers, then use EMPTY. If you subscribers not only act on emit, but also on completion and you want to avoid this behaviour, use NEVER.

I’ve been developing in Angular for many years now, and something that either passed me by, or I just never ran into a problem with it, is that if a route has multiple route guards, they will all run at once asynchronously. Obviously the result of all of these are waited on, and the route will not navigate unless the guards succeed, but the guards themselves all fire at once. In some scenarios this is desirable for speed, but in others… a little less so.

I had a scenario where I had two route guards. The first was simply to check if the user was logged in via an OAuth process. The second guard was to check if the user had a particular role, but it essentially depended on the first route guard checking the login status. I assumed (wrongly), that this set up would work as the first guard checks if the user is logged in, *then* we check the role they have in the second guard. Instead, I ran into multiple issues where the second guard would fire before the first, breaking my entire application.

The solution is that we need a “Combined” guard to run a given set of guards one after the other, synchronously. I made one like so :

@Injectable({
  providedIn: 'root',
})
export class CombinedGuard implements CanActivate {
  constructor(private injector: Injector) {
  }

  async canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Promise {
    const guards = route.data.guards || [];
    for (const guard of guards) {
        const instance: CanActivate = this.injector.get(guard);
        let result  = instance.canActivate(route, state);

        //Depending on the route result, we may need to await upon it in different ways.
        if(result instanceof Promise) {
            result = await result;
        }

        if(result instanceof Observable) {
            result = await result.toPromise();
        }

        if (result === false || result instanceof UrlTree) {
            return result;
        }
    }
    return true;
  }
}

To use this, we need to use the data property of a route to set the guards rather than the guard property :

{
  path: 'admin',
  canActivate: [CombinedGuard],
  data: {
    guards : [LoginCheckGuard, AdminRoleGuard],
  }
}

Notice how we pass our two guards (LoginCheckGuard and AdminRoleGuard) as data properties, not inside the canActivate, and instead pass the CombinedGuard as the actual canActivate guard.

Surprisingly, I found many people with the same issue complaining on the Angular GIT repository, but as of yet, no official fixes. It does seem slightly strange to me as running guards in a particular order does seem like a common use case, but for now, you’ll have to use the CombinedGuard.

Coming from a C# background, I don’t tend to use Discriminated Unions a whole awful lot. By Discriminated Unions, I mean having a method that may take multiple different types, or may return multiple different types.

If you’ve come from a C# world, it’s basically like method overloads when passing parameters into a method. And the other way, it allows you to make a method that could return one of many different types, that don’t necessarily have to have an inheritance relationship between them.

Let’s see how this might work :

class Plane {
}

class Car {
}

getVehicle() : Plane | Car {
    //Either of these are valid. 
    return new Plane();
    //return new Car();
}

It’s somewhat strange at first to get used to this ability if you’ve never used a language that uses unions. Most developers would instead make a “base” class of “Vehicle” and make both Plane and Car inherit from Vehicle, and then you don’t need a union. Which.. In my view is probably valid.

But lets say you can’t do that, and you are dealing with code that either returns a Plane or Car, *or* code that accepts a Plane or Car. You’re going to need to know at some point, which one you have. Because if the objects were identical, you probably wouldn’t need this union at all. Type checking in Typescript on the surface seemed easy, but I went down a bit of a rabbit hole through documentation and guides that weren’t always clear. So I want to try and simplify it down all right here, right now.

Using The TypeOf Operator

Javascript actually has a typeof operator itself that can tell you which type a variable is. As an example, we can do things like :

let variable1 = 'abc';
let variable2 = 123;
console.log(typeof variable1);//Prints "string"
console.log(typeof variable2);//Prints "number"

But.. This isn’t as helpful as you might think. Other than the fact that it returns the “type” as a string, which is rather unhelpful in of itself, it doesn’t work with complex types. For example :

let myCar = new Car();
console.log(typeof myCar);//Prints "object"

For all custom classes (Which, in modern JavaScript you will have many), the return type is only ever object. That’s because the typeof operator can only tell you which primitive type your variable is, but nothing beyond that.

For this reason, while it may be helpful for telling strings from numbers, anything more, typeof is out!

Using The InstanceOf Operator

That brings us to the instanceof operator. It’s actually rather simple! We can just change our code to work like so :

let myCar = new Car();
console.log(myCar instanceof Car);//Prints true

Works well and we can now tell if our variable is an instance of a car. But there is a caveat, and it’s around inheritance. Consider the following code :

class Car {
}

class Honda extends Car {
}

let myCar = new Honda();
console.log(myCar instanceof Car);//Prints true

Notice that even though our variable holds a “Honda”, it still returns true as a car. For the most part, this is how all programming languages work so we shouldn’t read too much into this “limitation” as it’s really just polymorphism at play, but it’s still something to keep in mind.

Alas, we have an issue! A really smart developer has come along and said that interfaces are the new hip thing, and we should switch all classes to interfaces in our front end code. So we have this :

interface Car {
}

let myCar = {} as Car;
console.log(myCar instanceof Car);//Error 'Car' only refers to a type, but is being used as a value here.

This time around, we don’t even get to run our code and instead we get :

'Car' only refers to a type, but is being used as a value here.

What’s going on here? Well.. the instanceof operator works with classes only, not interfaces. Gah! OK but actually there is a way to check this further!

Using The As Cast Operator

Consider the following code (And yes I know it’s a fairly verbose example, but should hopefully make sense!)

interface Car {
  carMake : string;
}

let myCar = {carMake : 'Honda'};

let processCar = (car : object) => {
  //Some other code. 
  if(car as Car){
    console.log((car as Car).carMake);
  }
}

processCar(myCar);

Notice how we can cast our variable to a Car, and check if it has a value (by using a truthy statement, it will be undefined otherwise). Casting is actually a great way to determine whether variables are instances of an interface.

Using Typescript Type Guards

One thing I want to point out about the above code is that we have had to actually cast the car twice. Notice that inside the console log, we had to cast again for intellisense to pick up we were using a Car.

console.log((car as Car).carMake);

Typescript has a way to deal with this however. It’s called “Type Guards”, and it allows you to write code that will not only check an object is a given type, but that Typescript from that point on can treat the variable as the type.

For example, we can create a custom type guard like so :

function isCar(car : any): car is Car{
  return (car as Car) !== undefined;
}

The magic sauce here is the return type. It’s actually “car is Car”. That tells Typescript that should this return true, the input variable can be treated as a Car from this point onwards. This allows us to change our code to instead be :

let myCar = {carMake : 'Honda'};

let processCar = (car : object) => {
  //Some other code. 
  if(isCar(car)){
    console.log(car.carMake);
  }
}

processCar(myCar);

Notice how inside our console log, we didn’t have to cast again to have it act as a car.

This is a really important concept when talking about type guards. It’s not just a way to create a nice fancy method that can be used to check types, it actually allows Typescript to start treating what could be an unknown object type, as a very specific one within that code block.

Sometimes Angular can be a real headache when it comes to some really basic use cases, especially when form building.

Case and point, I recently had to get all controls within a ngForm so that I could run a custom method on them. At first, I figured that something like so would suffice :

let myControls = myNgForm.form.controls; //<-- This should get all controls right?

But actually this only returns the name of the inner controls, but not the control object itself. Luckily, there is a simple way to then get the control based on the name using a for loop :

for(const field in myNgForm.form.controls) {
    const control = myNgForm.form.get(field); //This gets the actual formControl. 
}

This works perfectly and our control variable is now set to the actual AbstractControl object (Which we can then cast to a FormControl/Group/Form etc if we need to).

There’s one more step we need to do though. The problem with this is that I don’t want to have to copy and paste all of this around my code base. So let’s make it reusable!

The first thing we need to do is create a file called ng-form.extensions.ts, hopefully in an extensions folder, somewhere in our project. Inside of it, we want the following :

import {  AbstractControl, NgForm } from '@angular/forms';

declare module "@angular/forms/" {
    interface NgForm {
      getAllControls(this:Form) : AbstractControl[];
    }
}
NgForm.prototype.getAllControls = function(this:NgForm) {
    let controls : AbstractControl[] = [];
    for(const field in this.form.controls) {
        const control = this.form.get(field);
        controls.push(control);
    }
    return controls;
}

If you haven’t seen this type of code before, it’s how we can add “extension” methods to existing interfaces from Angular. What we are doing here is essentially telling Typescript that NgForm actually has another method called “getAllControls” available to it, that returns an array of AbstractControl.

Anywhere we want to use this, we can simply add an import to the top of whatever file :

import 'src/app/_core/extensions/ng-form.extensions'; //Obviously this is the actual location of your extensions file

And then use it like any other method in your component :

this.myForm.getAllControls();

Nice and easy! And super re-usable. The best thing is that you can add more and more extensions to your NgForm any time you feel there is something missing from the default behaviour, and you don’t need to create all sorts of complex services that take an NgForm parameter, you can add it directly onto the interface itself!

A very common question I field from developers new to Angular is what does the “static” property do when using ViewChild. For example, if we have code like so :

@ViewChild(ChildComponent, {static : false}) 
childComponent : ChildComponent;

What exactly does setting static to false do?

I think the documentation is actually rather light and I’ve seen lots of posts around the subject that explain the end behaviour of setting static to true or false, but not what it’s actually doing. A bit like describing the symptoms rather than what’s actually going on.

So let’s break it down!

What Does Static Actually Do

Static stands for whether the ViewChild is “static” content e.g. Always available on the page, no matter page bindings, API calls, ngIfs etc. When set to true, we are telling Angular that the ViewChild will be available at anytime, so simply query for the ChildComponent at the earliest lifecycle hook available and then never query again.

However, if we set static to false, we are saying that the ViewChild will be available at a later time, but it’s dependant on a condition (Such as an API call, or a simple component property binding), and therefore we must check for the ViewChild every time ChangeDetection runs. Understandably, this can create a higher performance load because we must always be checking if our ChildComponent is available any time the component changes.

Access In Component Lifecycle Hooks

I want to talk a little bit about how the setting of the static property affects how early we can access the ViewChild. This is one of those symptoms I talked about earlier. Setting static to true or false does affect which lifecycle hook you can access the ViewChild, but it’s more a side effect of what static is actually doing rather than the intention of the property.

When static is set to false, it is only available during the ngAfterViewInit lifecycle hook at the very earliest because this is the very first lifecycle hook that runs after ChangeDetection for the component.

In code form, if we have a component like so :

export class AppComponent implements OnInit, AfterViewInit {
  @ViewChild(ChildComponent, {static : false}) childComponent : ChildComponent; //Notice the static false

  ngOnInit(): void {
    console.log(this.childComponent);
  }

  ngAfterViewInit(): void {
    console.log(this.childComponent);
  }
}

Notice that static is set to false. And therefore, our ViewChild is not available in ngOnInit. If we run the code, we get this :

undefined
ChildComponent

Changing the code to instead use static true

export class AppComponent implements OnInit, AfterViewInit {
  @ViewChild(ChildComponent, {static : true}) childComponent : ChildComponent; //Notice the static false

  ngOnInit(): void {
    console.log(this.childComponent);
  }

  ngAfterViewInit(): void {
    console.log(this.childComponent);
  }
}

Instead now when we run our code, our ViewChild is available earlier.

ChildComponent
ChildComponent

So Should We Always Use Static True Then?

So the question then becomes, if we can get access to our ViewChild earlier, why not just always make it available as soon as possible? There’s actually one big reason, but I’ll give two examples to show how always setting static to true on ViewChild can cause a few headaches.

In this first example, I’m going to add a boolean to our code on whether we should show our ChildComponent or not. The code behind looks like so :

export class AppComponent implements OnInit, AfterViewInit {
  shouldShow = true; //This is our new boolean. 
  @ViewChild(ChildComponent, {static : true}) childComponent : ChildComponent;

  ngOnInit(): void {
    console.log(this.childComponent);
  }

  ngAfterViewInit(): void {
    console.log(this.childComponent);
  }
}

With HTML utilizing a simple ngIf :

<app-child *ngIf="shouldShow"></app-child>

When static is set to true, our output is :

undefined
undefined

So not only is ViewChild not available during ngOnInit, it’s actually never available. And the reason is that when we set static to true, Angular only tries to find our ViewChild *once*, and only once. If our ViewChild is not available in the DOM when Angular checks, it is never queries for again. Even in this case where shouldShow is a constant value, ChangeDetection does not run until later in the component lifecycle – after Angular tries to fetch a ViewChild initially.

However if we change static to false, then instead we get this :

undefined
ChildComponent

Because ngAfterViewInit runs after the first ChangeDetection cycle, our component is available, and because setting static to false means after every ChangeDetection, we re-query, we are able to find our ChildComponent.

How about a second example? Let’s take this code :

export class AppComponent implements OnInit, AfterViewInit {
  shouldShow = false; //This is our new boolean. 
  @ViewChild(ChildComponent, {static : false}) childComponent : ChildComponent;

  ngOnInit(): void {
    console.log(this.childComponent);
    timer(2500).subscribe(x => 
      {
        this.shouldShow = true;
      });

    timer(3000).subscribe(x => 
      {
        console.log(this.childComponent);
      })
  }

  ngAfterViewInit(): void {
    console.log(this.childComponent);
  }
}

I want to use this example because it shows it’s not about Lifecycle Hooks at all. It’s just that some people boil it down to something like :

  • Static = true. Access in ngOnInit
  • Static = false. Access in ngAfterViewInit

And the reality is it’s actually got nothing to do with that. It’s about ChangeDetection. In our above example, both the logs from ngOnInit *and* ngAfterViewInit will be false, however when our timer goes off, and we set shouldShow to true, and then 500ms later we check the ChildComponent, it will be available.

Which One To Use?

The rules for which one to use is actually quite simple.

  • If your ChildComponent is hidden or dynamically loaded in some way via component binding (Either with property binding or an API call), then you *must* set static to false.
  • If your ChildComponent is always available on the page, and is never hidden. Then you can use *either* static false or static true. But setting static to true is more performant, and gives you earlier access to the component (if required).

This article is part of a series on Inter-Component Communication in Angular. While you can start anywhere, it’s always best to start at the beginning right!

Part 1 – Input Binding
Part 2 – Output Binding
Part 3 – Joining Service
Part 4 – ViewChild


We’re now onto our final method of communicating between components in Angular. And this is one that I wasn’t sure if I should really write up. You see, using ViewChild to get components talking to each other, in my opinion, is the last resort. It isn’t that reactive and often runs into various race conditions because you aren’t using things like EventEmitters and data binding, and instead you are resorting to call methods directly.

For the above reasons, I’m going to make this short and sweet because for the most part, you won’t be using ViewChild to communicate between components, but it’s still good to know it’s an option.

Calling A Method Via ViewChild

Imagine I have my AppComponent like so :

import { Component, ViewChild } from '@angular/core';
import { ChildComponent } from './child/child.component';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent {
  @ViewChild(ChildComponent, {static : false}) childComponent : ChildComponent;

  runChild() {
    this.childComponent.run();
  }
}

That also has HTML like so :

<button (click)="runChild()">Click Me</button>
<app-child></app-child>

We now have an AppComponent, with a button that when clicked, will “run” our child component.

Also notice that we use the @ViewChild() directive to find the ChildComponent in our HTML. There are a few different ways to do this, for example you can use the #name format in your HTML and then use that name to find the child, but the important thing here is that we can use @ViewChild() to essentially find child elements within the html and get a reference to them.

Our ChildComponent looks like so :

@Component({
  selector: 'app-child',
  templateUrl: './child.component.html',
  styleUrls: ['./child.component.css']
})
export class ChildComponent {
  run() {
    //Maybe a bunch of logic here. And then we set a message. 
    console.log("Run Successfully!" );
  }
}

Nothing too fancy. Upon running this solution, when we click the button in our AppComponent, it calls the run method of our ChildComponent, and everything is great! So, the first thing to get into is..

Where Should You Use ViewChild

ViewChild in my opinion has a very discrete use case. When you need to call a specific method within a child component *and* you would like to subscribe to it (Or await a promise from it). It can allow you to do sync calls to a child component, and actually wait till it’s done before being completed.

Where you shouldn’t use ViewChild is :

This article is part of a series on Inter-Component Communication in Angular. While you can start anywhere, it’s always best to start at the beginning right!

Part 1 – Input Binding
Part 2 – Output Binding
Part 3 – Joining Service
Part 4 – ViewChild


In our two previous posts in using Input Binding, and then Output Binding for intercomponent communication, one thing is common between the two – there needs to be a direct parent/child relationship between the two components that need to talk to each other. While this is often the case, with a parent component passing down values to a child component, it’s also pretty common that components need to talk to each other either as siblings, or even distant cousins! For that, the best thing to use, hands down, is a “joining service”.

A good example of this is our guide to building a multi step wizard in angular. There, we used a joining service to hold the values of the individual form steps, and then at the end bring them all together. While this may not seem like “inter-component communication” at first, when you think about how each step of the wizard needs to pass on it’s values to the next step, then it totally makes sense!

Value Sharing via Joining Service

The first example I want to show is how we can share values between services. It’s actually pretty simple. Let’s create a service called “MyJoiningService” :

@Injectable({
  providedIn: 'root'
})
export class MyJoiningService {

  constructor() { }

  public myValue : string;
}

Nothing too fancy, we are just exposing a string value. Importantly, we have added the providedIn: “root” declaration. This means (In simple terms), that there will only ever be one instance of this service available, no matter which component uses it. So if we do this in our FirstComponent :

export class FirstComponent implements OnInit {

  constructor(private myJoiningService : MyJoiningService) { }

  ngOnInit() {
    this.myJoiningService.myValue = "ABC";
  }

}

And then in our second component we do :

export class SecondComponent implements OnInit {

  constructor(private myJoiningService : MyJoiningService) { }

  ngOnInit() {
    let someValue = this.myJoiningService.myValue; //The value is ABC
  }

}

The myValue property inside JoiningService is now shared between two components, even if the two components aren’t related to each other directly in HTML.

It’s really not rocket science and when spelled out like this, it probably seems a little too easy. Really the providedIn declaration is doing the magic for us, being able to share the exact same instance/singleton within our application.

Now this example works, but only if these two components aren’t on the same page. Otherwise we have a little bit of a race condition in that our SecondComponent needs to read the value *after* it has been set by the FirstComponent. But what if the value is set by a user interaction? How can we “alert” the SecondComponent the value has changed, by way of our joining service?

Using Subjects via Joining Service

To solve our problem of being “notified” when a new value is passed into our Joining Service, we are going to use Subjects. So let’s modify our service to look like so :

export class MyJoiningService {

  constructor() { }

  private myValue = new ReplaySubject<string>(1);

  public addMyValue = (value : string): void => this.myValue.next(value);

  public onMyValue = this.myValue.asObservable();
}

We have made “myValue” now be a Subject (Although in this example, we are using ReplaySubject, for why that is, check out our article on Subject vs ReplaySubject here : https://tutorialsforangular.com/2020/12/12/subject-vs-replaysubject-vs-behaviorsubject/).

We then have two additional properties. The first is an “addMyValue” method, that adds a value into the subject. And the second is an “onMyValue” property which acts as an observable for components to subscribe to changes.

We can then modify our FirstComponent like so to pump a value into the joining service :

export class FirstComponent implements OnInit {

  constructor(private myJoiningService : MyJoiningService) { }

  ngOnInit() {
    this.myJoiningService.addMyValue("ABC");
  }
}

And our SecondComponent can then listen for the value like so :

export class SecondComponent implements OnInit {

  someValue : string;
  constructor(private myJoiningService : MyJoiningService) { }

  ngOnInit() {
    this.myJoiningService.onMyValue.subscribe(x => {
      this.someValue = x;
    })
  }

}

Note that the use of the ReplaySubject is nice here because it doesn’t matter when the SecondComponent starts listening – we’ve managed to remove our race condition! Even if it “subscribes” late, because we use a ReplaySubject, it will still give us the last value that was passed into the JoiningService.

I use this pattern a tonne when trying to sync up components that have no direct relationship to one another. For example, a recent application of mine was built to receive inbound calls via Twilio in the browser, however when an inbound call was received, we wanted to disable some functionality of a couple of components so that you didn’t get direct messages while on your inbound call. We did this by creating a call service that would be able to alert other components when a call was in progress, without the need for direct component to component communication.

The other obvious benefit of using this is that it decouples components from one another. In our example, FirstComponent doesn’t know about SecondComponent, and vice versa. FirstComponent just knows that it can push values into the joining service for any number of other components to listen to, without needing to know who is subscribing to the observable.

Next

In the final part of our series, we are going to look at how we can use ViewChild in very select scenarios where we have a direct component relationship, but need to do more than just pass values around. It’s a rare usecase, but I do end up using it once or twice in each project when I’m in a jam. Check it out here : Inter-Component Communication In Angular – ViewChild

This article is part of a series on Inter-Component Communication in Angular. While you can start anywhere, it’s always best to start at the beginning right!

Part 1 – Input Binding
Part 2 – Output Binding
Part 3 – Joining Service
Part 4 – ViewChild


In our previous post, we talked about inter-component communication using the Input declaration, to pass values into a child component. Now, it only makes sense that we talk about using the Output keyword, to pass values from a child component to it’s parent. To me, the Output declaration is easier and more straight forward than Input, but let’s get started and see what you think!

Basic Output Usage

At it’s simplest, we can mark an EventEmitter using the @Output() declaration on a child component like so :

export class ChildComponent {
  @Output() message : EventEmitter<string> = new EventEmitter<string>();

  sendMessage() {
    this.message.next("Hello World!");
  }
}

Then when we place this component on any page, we can modify it’s tag to listen for the message event :

<app-child (message)="onMessage($event)"></app-child>

Where “onMessage” is a method on the parent component that should be run when the value is passed back, and $event is the value of the message.

Very easy!

One thing that strangely I find people don’t realize initially, is that your event does not actually need to hold a value. For example, if you want to raise an event from your component when a click event happens, I often see people do something like this :

export class ChildComponent {
  @Output() click : EventEmitter<boolean> = new EventEmitter<boolean>();

  sendClick() {
    this.click.next(true);
  }
}

Notice the boolean and returning true? I don’t know why, but I’ve come across this in many projects, sometimes even with number values where they just return “0”. Little do they know, that EventEmitter is quite happy with a void type like so :

export class ChildComponent {
  @Output() click : EventEmitter<void> = new EventEmitter<void>();

  sendClick() {
    this.click.next();
  }
}

And that’s honestly all there is to the output keyword. Create an EventEmitter, add the @Output() declaration, listen to it in the parent. Done!

Two-Way Binding

Next we want to talk about two way binding. Two way binding is actually nothing more than syntax sugar for taking values emitted, and automatically setting them a variable. Let me demonstrate with an example.

Imagine I have a child component that looks like so :

export class ChildComponent {
  @Output() messageOut : EventEmitter<string> = new EventEmitter<string>();
  @Input() message : string;

  changeMessage() {
    this.messageOut.next("Hello World!");
  }
}

Here we can take a message in using the @Input() message line. We can also output a message through the messageOut EventEmitter. All seems pretty normal.

Next, we head to our parent component, and add the control like so :

<app-child [message]="myMessage" (messageOut)="onMessageOut($event)"></app-child>

And the code behind of our parent component :

export class ParentComponent {
  myMessage : string = "ABC";

  onMessageOut(message : string) {
    this.myMessage = message;
  }
}

So really all we are doing when we receive a new message out, is setting our variable of “myMessage” to that value. It’s a pretty common use case. And because of that, Angular has come up with a convention to do all of this for you. It works like this.

First we go to our child component, and make sure that the Output variable is called the same as the input variable, with the suffix of change :

export class ChildComponent {
  @Output() messageChange : EventEmitter<string> = new EventEmitter<string>();
  @Input() message : string;

  changeMessage() {
    this.messageChange.next("Hello World!");
  }
}

Then we head to our child component, and we can essentially wrap the binding with both the [] and () :

<app-child [(message)]="myMessage"></app-child>

Inside our actual Parent code behind, we can remove all event handling :

export class ParentComponent {
  myMessage : string = "ABC";
}

And this now works just the same! Angular uses the convention of an output variable named the same as an input, but with the suffix of “change” to mean that when next is called on the EventEmitter, you want the value to be set on the bound variable.

It’s actually fairly simple once you know it, but I’ve seen some really roundabout ways to achieve the same thing. Generally people actually ask things like “How do I name the output variable the same as the input” or “How do I combine input and output into one variable like ngModel?”. And what they actually mean is how do I two way bind in Angular!

Two Way Binding While Keeping Events

I just want to make a quick note on the work above. Commonly people tell me they don’t want to use two way binding because they still need an event to know when the value changes. Two way binding does not hide the event at all.

In our example above, we can actually still use the following :

<app-child [(message)]="myMessage" (messageChange)="onMessageChange($event)"></app-child>

So we get two way binding on the myMessage variable, but we can still listen for the event too! The order of events is that myMessage will be set by Angular before the messageChange event is run. I wouldn’t rely on this, but it’s the way it works right now.

You can even see this in action with ngModel like so :

<input type="text" [(ngModel)]="myMessage" (ngModelChange)="onMessageChange($event)">

New Angular developers tend to think that ngModelChange is some magic event that the Angular team are exposing so you can hook into the ngModel EventEmitter. But actually, it’s just a byproduct of ngModel being a two way bind (Notice that ngModelChange is just ngModel with the change suffix)!

Next

Next we’re going to take a walk through using a “joining service”. A joining service is required when your components may not have a direct relationship between each other (e.g. They are not parent/child). But we can still pass values between components using a service to facilitate the communication! Check it out here : https://tutorialsforangular.com/2021/05/01/inter-component-communication-in-angular-joining-service/

This article is part of a series on Inter-Component Communication in Angular. While you can start anywhere, it’s always best to start at the beginning right!

Part 1 – Input Binding
Part 2 – Output Binding
Part 3 – Joining Service
Part 4 – ViewChild


Inter-Component communication refers to the way that we can get components talking to each other. Sounds simple?! And for simple scenarios where there is a direct child to parent relationship, it is! But when components are not directly placed within one another, or they need to do more than just pass a variable back and forth, things can actually get complicated fast.

Rather than start at the complicated scenarios, we are still going to cover off the basics such as Input binding as for the most part, this is going to be your bread and butter. Then later on, we can start getting into more complicated scenarios such as using a joining service, or using the ViewChild declaration!

The first way we are going to get our components talking to each other is using one-way binding with the “Input” keyword. This is going to be by far the most common method of passing values into a child component, and it’s also one of the easiest. So without further ado, let’s get going!

Basic Input Usage

At it’s simplest, a component can use the “Input” declaration on a component, to say that any parent can pass in a value. For example, our ChildComponent may look like so :

export class ChildComponent {
  @Input() message : string;
}

And when we place this component on any page, we can do something like so :

<app-child [message]="'Hello World!'"></app-child>

Easy right! There really isn’t much to it!

Why The Double Quotes?

A common question I get asked is why do we double quote the text going in? e.x. Why do we have both ” and ‘ wrapped around our Hello World?

[message]="'Hello World!'"

The answer is actually quite simple. When we use the square brackets syntax [] it means we are doing a “one way” bind (From our parent to our child). This one way binding syntax expects either a variable, or a constant. However I often see people making the mistake of doing this :

[message]="Hello"

Since the message input variable is a string, what’s the big deal right? Well when you don’t wrap ‘Hello’ in single quotes, what you are telling Angular is that you are passing a variable. In this case, Angular looks for a variabled named “Hello”, doesn’t find one, then passes through an undefined value. This is why you often single variables wrapped in single quotes, even when passing strings through.

Timing Is Everything

The next problem people generally run into with Input variables is to do with timing. Often, start up code will live in an ngOnInit like so :

export class ChildComponent implements OnInit {
  @Input() message : string;
  
  constructor() { }

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

}

But what happens if message is not set by the time the component is initialized? A common reason for this is that maybe string comes from an API, and therefore there is a bit of a race condition with the API returning and passing the message into the child component, and the child component actually being initialized.

For these sorts of race conditions, I generally go with property getters and setters. That means turning my component into something more like so :

export class ChildComponent implements OnInit {

  _message : string;
  @Input() set message (value : string) {
    this._message = value;
    this.setup();
  }
  
  constructor() { }

  ngOnInit() {
  }

  setup() {
    console.log(this._message);
  }

}

Now it doesn’t matter on the timing of when a message will be set. Each time the input variable is changed, we will kick off the setup routine. I use this in almost all of my projects as it’s a pretty quick and simple way to allow async one way bindings to occur, where I don’t need to manually be checking change tracking myself.

Timing Complex Objects

Our above example works because when a new message is passed in, the reference changes and the setter is called. But imagine we have a more complex object like so :

export class ChildComponentConfiguration {
  message : string;
}

With our child component like so :

export class ChildComponent implements OnInit {

  _config : ChildComponentConfiguration;
  @Input() set config (value : ChildComponentConfiguration) {
    this._config = value;
    this.setup();
  }
  
  constructor() { }

  ngOnInit() {
  }

  setup() {
    console.log(this._config.message);
  }

}

Imagine that we pass in our configuration object, then at a later point, the message object is changed. Under this scenario, our setter will never be called because the configuration object itself has not changed, only the properties within it.

Now, what I’m going to suggest has it’s own pros and cons. You should definitely read more about implementing your own DoCheck methods, but.. it works a bit like this :

export class ChildComponent implements OnInit, DoCheck {
  @Input() config : ChildComponentConfiguration;
  
  differ: any;
  
  constructor(private differs: KeyValueDiffers) { 
    this.differ = differs.find({}).create();
  }

  ngDoCheck(): void {
    const changes = this.differ.diff(this.config);
    if(changes) {
      changes.forEachAddedItem(change => {
        //The message has changed. 
        if(change['key'] == 'message')
        {
          this.setup();
        }
      });
    }
  }

  ngOnInit() {
  }

  setup() {
    console.log(this.config.message);
  }
}

Let’s walk through this a little. The first thing you will notice is that we implement the “DoCheck” interface, this means that when ChangeTracking is called on our component, we can implement custom logic to say what’s changed.

In our constructor, we take what’s called a “KeyValueDiffers”. The main thing to note is that this allows us to compare “differences” between an object each time the DoCheck method is called. Essentially, if the message has changed between two calls of ngDoCheck, then the differ will pick it up.

Finally, once we have the changes we need to loop through them and check them. We do this by checking the change “key” which is the name of the property that changed. If it’s the “message” that’s changed, then we call setup.

There’s obviously come caveats with using this :

  • ngDoCheck is called very often. It shouldn’t be taken lightly as it can cause an app to slow to a crawl. Much like using an impure pipe!
  • The differ can actually know when values are unset or set for the first time instead of modified, so play around with it a little bit
  • Again, you only need this if a property of your input variable is “delayed” being changed, but that could even be because a user must click a button first, not just waiting on API calls.

Overall, implement DoCheck is a heavy handed approach, but it’s one to keep in your tool arsenal if you have no other option.

Next

Coming up next is using EventEmitters to handle events being passed up from child to parent! Check it out here : https://tutorialsforangular.com/2021/04/04/inter-component-communication-in-angular-output-binding/