Why your Angular App is not Working: 11 common Mistakes

1. Import required Angular Modules

Probably the most common mistakes, beginners make, is not to import the required modules. Why? Because they don’t even know about them. Of course, they don’t. Getting an overview of the angular framework takes some time. Unfortunately, that often results in mysteriously not working angular applications. The errors you get look something like this:

 Can't bind to 'ngModel' since it isn't a known property of 'input'

This error indicates, that the angular Forms Module has not been imported into your module.

 Unhandled Promise rejection: No provider for HttpClient!

This error tells you, that you have not imported the angular HttpClient Module into your (root) module.

@NgModule({
  declarations: [AppComponent],
  imports: [BrowserModule, FormsModule, HttpClientModule],
  bootstrap: [AppComponent],
})
export class AppModule {}

 BrowserModule
FormsModule // required to use ngModel directive
HttpClientModule // formerly HttpModule
RouterModule
BrowserAnimationsModule / NoopAnimationsModule
 

 MatMenuModule
MatSidenavModule
MatCheckboxModule
MatDatepickerModule
MatInputModule
...
 

2. Don’t use DOM references before they exist (@ViewChild)

With the help of the @ViewChild decorator, angular makes it very easy to reference specific child elements (html nodes or components) of your component. All you need to do is to add a reference identifier to the node or component inside of your template. Just add a # followed by a name beside the nodes attributes.

<div #myDiv></div>

We can now reference that element from our component. If it is a component, we can call its public methods and access its properties. If it is a plain HTML element, we can change its style, its attributes or its children.

Angular automatically assigns the reference to a property of our component, if we decorate that property with the @ViewChild() decorator. Make sure, to pass the reference name to the decorator. For example @ViewChild(‘myDiv’).

import { ViewChild } from '@angular/core'
 
@Component({})
export class ExampleComponent {
  @ViewChild('myDiv') divReference
}

import { ViewChild, OnInit } from '@angular/core'
 
@Component({})
export class ExampleComponent implements OnInit {
  @ViewChild('myDiv') divReference
 
  constructor() {
    let ex = this.divReference.nativeElement // divReference is undefined
  }
 
  ngOnInit() {
    let ex = this.divReference.nativeElement // divReference is undefined
  }
}

import { ViewChild, AfterViewInit } from '@angular/core'
 
@Component({})
export class ExampleComponent implements AfterViewInit {
  @ViewChild('myDiv') divReference
 
  ngAfterViewInit() {
    let ex = this.divReference.nativeElement // divReference is NOT undefined
  }
}

import { ViewChild, AfterViewInit } from '@angular/core'
 
@Component({})
export class ExampleComponent implements AfterViewInit {
  @ViewChild('myDiv') divReference
 
  ngAfterViewInit() {
    let ex
    if (this.divReference) {
      ex = this.divReference.nativeElement // divReference is NOT undefined
    }
  }
}

3. Don’t manipulate the DOM directly - Angular Universal

Manipulating the DOM in angular directly is not only considered bad practice. It can also result in your angular app not working in a different environment other than the browser. The most popular example is the so-called Angular Universal project, which enables your angular application to be rendered server-side. But why should you even care? Read all about Angular universal and server-side rendering in this step-by-step guide.

THIS EXAMPLE DOES NOT WORK

import { ViewChild, AfterViewInit } from '@angular/core'
 
@Component({})
export class ExampleComponent implements AfterViewInit {
  @ViewChild('myDiv') divReference
 
  ngAfterViewInit() {
    let ex = this.divReference.nativeElement
    ex.style.color = 'red' // does not work on the server
  }
}

import { ViewChild, Renderer2 } from '@angular/core'
 
@Component({})
export class ExampleComponent {
  @ViewChild('myDiv') divReference
 
  constructor(private renderer: Renderer2) {}
}

import { ViewChild, Renderer2, AfterViewInit } from '@angular/core'
 
@Component({})
export class ExampleComponent implements AfterViewInit {
  @ViewChild('myDiv') divReference
 
  constructor(private renderer: Renderer2) {}
 
  ngAfterViewInit() {
    if (this.divReference)
      this.renderer.setStyle(this.divReference.nativeElement, 'color', 'red')
  }
}

4. Avoid duplicate providers overriding each other

You may have heard that angular utilizes a concept called dependency injection. With the help of dependency injection, you can request instances of your services in your constructor.

For that to work, services or broader injectables have to be registered in the provider section of your component or module decorator. The most common method is to provide it at a module level.

The problem here, is, that angular uses a hierarchical dependency injection system. That means, that services/injectables provided in the root module (AppModule) are available to all components in that module. And because that module should contain all other components and modules, the services provided here are available in the whole application.

If you provide a service to a sub-module, it is only available to that sub-module. That also means, that if you provide the services in both modules, the components in the sub-module get a different instance of the service than any other component. That can lead to all kinds of errors if you assume your service to be the only instance in your application (singleton).

The solution is simple. Do only provide your services once. Generally in the AppModule. Unless you know what you are doing, you should stick to that, especially in the beginning. In 99% of the cases, you should be fine doing so.

5. Angular Guards are not a Security Feature

Angular Guards are a great way to artificially restrict access to certain routes. For example, to check if a user is logged in, before actually showing him the page. Here is a quick example of such a guard:

import { Injectable } from '@angular/core'
import { AuthenticationService } from './authentication.service'
import { CanActivate } from '@angular/router'
 
@Injectable()
export class AuthGuard implements CanActivate {
  constructor(private authService: AuthenticationService) {}
 
  canActivate() {
    return this.authService.isAuthenticated()
  }
}

Of course, because the guard is an observable, it has to be provided, as well.

@NgModule({
  providers: [AuthGuard, AuthenticationService],
})
export class AppModule {}

Finally, we have to tell it, which routes to protect:

 @NgModule({
  imports: [
  	RouterModule.forRoot([
	{
  		path: '',
  		component: SomeComponent,
  		canActivate: [AuthGuard]
	])
  ],
  providers: [
    AuthGuard,
    AuthenticationService
  ]
})
export class AppModule {}
 

6. Declare your Components only once

For components to work in angular, they have to be declared in a module. So as long as we have only one module (AppModule) and we register our components inside of it, there is no problem.

But when we start to bundle our application in modules, what you definitely should, by the way, you probably will encounter a common problem.

A component can only be declared in one module!

That is pretty much all there is to it. But what can we do, if we want to use our component in multiple modules?

The solution is simple. Just wrap your component into a module. Maybe a module per component is a bit too much, so why don’t we create a components module? That module can then be imported into other modules and you can use your components there. When you do so, make sure that you don’t only declare your components in that components module, but to also export them. Otherwise, they can only be accessed from within the module itself.

@NgModule({
  imports: [CommonModule],
  declarations: [LoginComponent, RegisterComponent, HelpComponent],
  exports: [LoginComponent, RegisterComponent, HelpComponent],
})
export class AuthenticationModule {}

7. Speed up your application by using *ngIf instead of the [hidden] attribute

Another common mistake is to confuse *ngIf and [hidden]. Choosing the right one of these can make quite a difference performance wise. So let’s take a closer look at both techniques.

<div [hidden]="isHidden"></div>

<div *ngIf="!isHidden"></div>

8. Avoid maintainability issues by wrapping in Services

As you may have noticed, we transitioned from critical errors to recommendations on how to improve your application. The last points will right about that: Making your applications faster, smaller, and better to maintain.

As a general advice, it is always good practice, to extract your core business logic into services. That way, it becomes much easier to maintain, as it can be swapped out and replaced by a new implementation in just a few seconds. The same goes for testing. Often times you need services that fetch external data, to fake the results in a test environment. If you fetch your data in services, that is an easy one. If not, good luck changing all the lines that need to be changed for that.

That advice is certainly true when using angular HttpClient. It should always be wrapped inside of a centralized service. That way, it not only stays testable, it is also easy to make changes to it. Imagine, your backend requires a new header to be passed with every request after a recent update. Without a centralized service, you now have to find all the lines across your whole app that are affected. Needless to say, that this would be far from optimal.

Instead, you should always wrap your HTTP-requests into services. In the worst case, that does not hurt you anyway. In the best case, it saves you (and your team) hours for the simplest tasks.

9. Gain performance and shrink size by using AOT in production

Starting an angular cli application via

 ng serve
 

or

 ng build
 

results in your application being build in regular mode. That means, that your application is shipped to the browsers, as it is. The browser has then to execute the angular compiler to convert your components and templates into executable JavaScript code. That process does not only take a lot of time. It also requires the whole angular compiler to be shipped with your application. In the current version of angular, the compiler has a size of ~1 MB (167kb gzipped). That’s huge!

Don’t believe me? You can analyze the angular bundle itself, by using a tool called webpack-bundle-analyzer. All you need to do is to create your bundle with the stats-json parameter.

 ng build --stats-json
 

Afterward, start the bundle analyzer like so:

 webpack-bundle-analyzer dist/stats.json
 

The tool will automatically open a browser window, showing you a similar result to the one above.

 ng build --prod --aot
 

 ng build --prod
 

10. Keep your Application Size small by only importing what you need

The next point is directly related to the previous. Again, we will take a look at the bundle size.

This time, the advice I give you is, to be careful what you import.

Every import statement you use increases the size of your bundle. Makes sense right? We are adding more code, so the size goes up.

The problem here is, that some libraries are quite huge. When using the wrong import statement, you can end up with the whole library in your application. Here is a much to popular mistake, that imports the whole RxJs library in your application.

import 'rxjs'

This tiny statement almost doubles the size of our application.

The point here is that this additional size is completely unnecessary. If you compare this bundle to the previous ones, you will notice, that these included RxJs as well. The difference is, that the previous bundle only contained the modules that are actually required. Using this import statement, we have imported just everything.

import 'rxjs/add/observable/of'
import 'rxjs/add/operator/map'
import 'rxjs/add/operator/switchMap'

import 'rxjs'

11. Do not leak Memory - Unsubscribe your Subscriptions

When dealing with RxJs Observables and Subscriptions, it can easily happen, that you leak some memory. That is because your component is destroyed, but the function you registered inside of the observable is not. That way, you not only leak memory but probably also encounter some odd behavior.

@Component({})
export class ExampleComponent implements OnDestroy {
  private subscriptions = []
 
  constructor() {
    this.subscriptions.push(this.anyObservable.subscribe())
  }
 
  ngOnDestroy() {
    for (let subscription of this.subscriptions) {
      subscriptions.unsubscribe()
    }
  }
}

Conclusion

In this article, we went through all the mistakes that are very commonly made in the beginning. Well, at least I did most of them…

I hope by sharing my mistakes, I could help you avoid them completely and provide you a better angular development experience that way.

If you liked this article, click the buttons below, and share it with your friends and colleges!

Never miss a post, by following me on twitter @malcoded.