Angular Forms: Reactive Forms

In last weeks blog post I have talked about the template-driven form approach in Angular. Beside why using forms I have also explained how to use template driven forms in Angular, how to use validation in template driven forms and what the advantages and disadvantages are. In this weeks blog post I want to show you how to use reactive forms in Angular.

Concept of Reactive Forms

The concept of Reactive Forms differs from the concept of template driven forms. In the template driven form approach you are building in the HTML template form controls like input or select and connecting these with ngModel to a model.

With reactive forms, there will be created a tree style data structure of form control object including validation etc. outside of the HTML template. This enabled control and manipulation of the form inside the component class.

Before we dive deeper into the different concepts and feature of reactive forms lets start to implement reactive forms.

Implementation of Reactive Forms

To use reactive forms we first have to import the ReactiveFormsModule from @angular/forms.

Notice that we have imported another module than in the template driven form approach. In the template driven approach we have imported the FormsModule from @angular/forms.

After setting everything up, we can start to build our template. To compare the template driven forms approach and reactive forms I will build a similar form like in last blog post.

So let’s start with the template of our reactive contact form.

As we can see, there are some changes we have made he compared to the template driven contact form.

First we have added an extra email validator, but we will talk about validation of reactive forms later.

On line 3 we declare the FormGroup of our reactive form which is called contactForm. It also has a ngSubmit event method like our template driven contact form. But instead of binding a model to our input and textares we use formControlName to access the FormControls of our FormGroup and direct them to our input and textarea elements. The FormControls in the FormGroup makes it possible not to use ngModel.

Notice that we have to made a few changes in our contact.component.ts file too:

Here we declare the contact FormGroup and build it with the FormBuilder which we also have to import from @angular/forms and declare it in the constructor.

In the ngOnInit() method we assign the FormControls to the FormGroup. The FormControls exist out of the value and the Validators we assign them. Here we assign name and message the required Validators and email the email Validator which checks if the typed in email address is a email address.

The isContactFormDisabled() method returns true if one of the three named validating FormControls (name, email and message) are invalid. If the isContactFormDisabled() is true, then the “Submit” button on the template will be disabled so the user can not submit his form.

The concept of validation here is working similar like in the template driven form approach, but there are some differences to it. First we define the validators in the FormControls and not in the HTML template. This enables us to test our form with classic unit testing. Remember that we only could test our template driven form with e2e tests! Second, we use the validators from the @angular/forms package (like required and email) and we can also build own validators to check the typed in input from the user. But this is a topic for another blog post.

Advantages and Disadvantages of Reactive Forms

So why would you use reactive forms?

  • Build for large scaled forms, FormGroup is being outsourced out of the template
  • Validation from @angular/forms and custom validation possible
  • Modification of the form outside of the template enabled unit testing

Why you should not use reactive forms?

  • Probably “too complex” for easy forms


So should you use reactive forms? Yes, if your application uses a lot of forms it is ideal. You can test it easily the outsourcing logic out of the template makes your application much cleaner.

But in some cases it is also recommending to use template driven forms. Anyway what forms you use, you should use also one kind of forms in your application. You could use both, but for a matter of consistency you should only use on type of forms in your Angular application.

If you have not read my last blog post, where I talk about template driven forms in Angular, you can do this by clicking here. I also would love to hear any feedback, you can either write a comment under this blog post or write me on Twitter.

Angular Forms: The Template-driven Form Approach

In Angular there existing two ways to create and use forms. To clear things up, I want to talk about both ways. In this post I want to talk about the Template-driven Form approach. In the next week blog post I will talk about Reactive Forms.

Why using forms?

You may ask yourself why should I use forms?

If you are developing a Fronted application it may be the case that you have to implement some kind of form, e.g. to sign in, to fill out some kind of user information etc. There are also application who are very form intensive and existing nearly only out of forms. And in some kind of application you even have to develop a form which spans about multiple pages aka a dialogs. In this case you have to deal with following problems:

  • Keeping track of the global state of your form
  • Dynamical changing the structure of forms during the filling out process of the user
  • Validation of user input and displaying error to the user
  • You need easy and quick access on the form

Luckily Angular can help here and give us as a developer some support to face this problems.

There exist the template driven form and reactive forms. In this blog post I will talk about the Template Driven Forms approach.

How it works

Since AngularJS (Angular 1.x) there existing the template driven approach. In the template driven you are using ngModel (in AngularJS ng-model) to keep your form synchronized with your model. When you are using the approach your only possibility to test your form is an End to End test (e2e), because you are need the access to the DOM to test your form.


To use the template driven approach you first have to import the FormsModule form @angular/forms into your app.module.ts

Assuming we have a typescript model for a contact form with name, e-mail, title and message. All of the attributes of this model should be strings.

Then we can build a form with the template-driven approach.

In the form element there are label and input/textarea field pairs. The labels functionality should be clear. In the input and textarea fields are just passing with ngModel fitting attributes from our contact model which we have declared in our contact.component.ts file. If we type in now in the input field the contact model change with it because of the two way data binding ability of ngModel.

We are even building some kind of required validation for name and message here, because the user should at least write his name and a message in a contact form. We will concentrate on validation in the next paragraph more intensive. We are validating the model on the submit button on line 34 so that form with a empty name and message can not be submitted. But if the user fills out the name and message field Angular enables the submit button and the user can submit his contact form and with it the contact model.

We have not implemented onSubmitContact() here, but we could simply implement it in the contact.component.ts so that we send the form to our backend and redirect the use in the client to a success page, which show him that he have send the contact form with success.


We have build in some logic validation in our contact form above. We can do this because Angular is tracking the form field and saves his states as CSS state classes. A form field is either touched or untouched, valid or invalid and pristine or dirty. The valid and invalid states should be clear. They describe if the value in a field is valid or invalid. There are much more native HTML form validation beside required like minLength or maxLength.

But what is about pristine/touched and touched/untouched?

The default state of a form field is pristine and untouched. If the user blur the form field, the form field will be set to touched and if the user change the value of a form field the form field will be set to dirty. This enable the application to only show an error if the user has actually edited the form field. Otherwise it would be very annoying for the user and therefore not very good for the user experience.

Advantages and Disadvantages of the Template-driven Form approach

So why would you use the template driven form approach?

Why you should not use the template driven form approach?

  • Larger forms are difficult to implement with the template driven form approach and will become complex.
  • Validation can only be tested with E2E (end to end) tests.


So should you use template driven forms? Yes, in some cases definitely. For little forms with a couple of fields (like contact form or login in/out form) they are perfect except you want to test you validation beside E2E tests. For more complex forms reactive forms could be the smarter choice. I will talk about reactive forms in next weeks blog posts.

Testing Services in Angular

Testing in Software Development is essential. In this blog post I will demonstrate how Testing in Angular works by testing a service with Jasmine and Karma by building a simple Angular application. I also try to answer the question why and how to test.

Why should you testing?

There are several good reason to write tests for your application.

  • Keeping sure everything works fine after making changes
  • Detecting early errors in development process
  • To ensure that the application does what it is supposed to do
  • To ensure that the application work on different devices, browsers etc.
  • To keep the quality of the final application high
  • Build up trust in the application

These are in my opinion the core reason why everybody should test. But there is another big reason why it is so important to test software. As software grows the complexity grows with it. For the developer it becomes more and more difficult to make chances in code and without testing the trust in their software application is low. Software application with tests have a high trust and in general high quality standards. Errors in code will be detected because of testing early in the development process and therefore the software developer are not scared to make changes in code. Because of that as complexity grows the development process still not slowing down heavily.

How should you test?

There are different kind of testing methods in Software Development. Let us quickly refresh the different kinds of testing in Software Development.

End-To-End-Tests (E2E)

End-To-End-Test are test where you directly test the running application. Selenium Web Driver is e.g. a popular framework to test them directly in the browser e.g. by clicking buttons and looking for the expected results. In Angular there is also Protractor, but I will not concentrate on these kinds of test in this blog post. E2E Tests are extremely useful, because they can represent the user behavior and can simulate all different kinds of use cases.

Unit Tests

Unit Tests call functions and other small pieces of code to make sure that they work as intended. In comparing to E2E Tests Unit Tests are only testing the logic and not the final behavior of your code.

Integration Tests

Integration Tests are similair to Unit Tests, but instead of testing only one by one each function and logic in your code, they are combining different logical parts of your code and testing if they work together. In the following GIF, you can see how the construct fails because there were only two unit tests but no integration test to ensure that a window can be opened.

Testing in Angular

Okay, now lets get started with Testing in Angular. As I said previous, I will concentrate on writing tests for services. I will do that with Jasmine and Karma.


Jasmine is a test framework for JavaScript application which is independent to other frameworks. It runs it test with a basic HTML test runner in the browser. Let us briefly look over the core features of Jasmine:

  • Suites describe(string, function) are functions which are containing a title and a functions which containing one or more specs.
  • Specs it(string, function) are function in Suits which are containing the logic of each test including the expectation(s).
  • Expectations expect(actual).toBe(expected) are assertions in the specs. If an assertion is false, the spec fails, otherwise the test is passed.
  • Matchers like toBe(expected), not or toBeNull() are helpers for assertions.


On the other hand Karma is a advanced test runner for writing Unit Tests. With Karma our Jasmine Test automatically can run in the browser if we are making chances to our test code. That is very nice.

Testing a Service

In the following I will code up a small Angular application with a service for testing purposes. You can find the code on GitHub.

After I have created a new Angular project with ng new angular-testing I go to the src/app folder and create a new service with ng g s app. The AppService will be a simple service which manages a string array. Let us define the tests first before we are building our service. The AppService should have 4 methods: getItems() should return the string array, addItem(item: string) should let us add new items to the array, deleteItem(index: number) should delete a item in the array with a specific index and last but not least getSize() should return as the length of the array. Our empty automatically generated app.service.spec.ts file from the Angular-CLI looks like following.

import {TestBed, inject} from '@angular/core/testing';

import {AppService} from './app.service';

describe('AppService', () => {
  beforeEach(() => {
      providers: [AppService]

  it('should be created', inject([AppService],
    (service: AppService) => {

Beside our AppService there are two more imports: TestBed and inject. TestBed is one of the most important testing utilities in Angular. It enables us to create a testing module of @NgModule. It can be further configured, but we do not need this for our use case. We just need to provide our service. We do this in beforeEach() to make sure that each spec is indpendet from each other. On the other side we have inject  which we will use for the specs. The inject function has two parameters. The first parameter is an array of all the services it want to inject from. In our case we just want to inject from our AppService. The second parameter corresponds to the services of the array in the first parameter. Okay, now we can write our tests for the our AppService to test the 4 methods.

import {TestBed, inject} from '@angular/core/testing';

import {AppService} from './app.service';

describe('AppService', () => {
  beforeEach(() => {
      providers: [AppService]

  it('should be created', inject([AppService],
    (service: AppService) => {

  it('should be empty', inject([AppService],
    (service: AppService) => {

  it('should contain an item with value first',
    inject([AppService], (service: AppService) => {
      const item: string = 'first';

  it('should contain an item with value first and an item with the value second',
    inject([AppService], (service: AppService) => {
      const firstItem: string = 'first';
      const secondItem: string = 'second';

  it('should contain an item with value second after deleting the first item',
    inject([AppService], (service: AppService) => {
      const firstItem: string = 'first';
      const secondItem: string = 'second';

  it('should contain an item with value first after deleting the second item',
    inject([AppService], (service: AppService) => {
      const firstItem: string = 'first';
      const secondItem: string = 'second';


Implementing the Service after defining the tests

After the tests have been write, we have to implement the function for our services before we can run our test.

import { Injectable } from '@angular/core';

export class AppService {
  private _items: string[] = [];

  constructor() { }

  public getItems(): string[] {
    return this._items;

  public addItem(item: string) {

  public deleteItem(index: number) {
    if (index < this.getSize()) {
      this._items.splice(index, 1)

  public getSize(): number {
    return this._items.length;

After we have done this, we can run npm test. This command opens a new browser window. It seems that all our test have passed.

Great! Let us go back to our tests and let them fail by changing a value in the assertions. I will change in the second the expected value from 0 to 1. We will have now a failing test.

We expected the length of an empty array to be 1, but this is wrong. This time we intentionally crashed our test, so let us correct it quickly by changing the expected value from 1 to 0.

Test-Driven Development (TDD) Approach

As you might noticed I first have wrote the tests before I have implemented the service. This is because I have tried to developed after the Test-Driven Development approach. The main idea here is to write the test before writing production code to be more productive and create a higher software quality. But this blog post is not about TDD, therefore I will not go in detail here. Maybe another time.

App Component

Okay, great. We have a service, which passed all the tests. We now have to write more production code to use the service in a real component. If you only were interesting in testing a service with Jasmine and Karma you can skip this part. In the last part of this blog post I will just finish building the Angular application.

To use the AppService in a component, we have to provide it in the app.module.ts. I will also import the ReactiveFormsModule here, because I will use it later in the app.component.ts to create a form.

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { ReactiveFormsModule } from '@angular/forms';

import { AppComponent } from './app.component';
import {AppService} from "./app.service";

  declarations: [
  imports: [
  providers: [AppService],
  bootstrap: [AppComponent]
export class AppModule { }

We will only have one component in our Angular application. The template will look like following.

<div class="container">
    There are {{appService.getSize()}} items in the list
  <form [formGroup]="form">
    <div class="form-group">
      <div class="row">
        <div class="col-md-2">
          <label for="addItem">New Item:</label>
        <div class="col-md-3">
          <input id="addItem" class="form-control" formControlName="item">
        <div class="col-md-1">
          <button type="submit" (click)="onSubmit()" class="btn btn-primary">Add Item</button>
    <ul *ngFor="let item of appService.getItems(); let i = index">
        <button style="margin-left: 20px" class="btn btn-danger" (click)="appService.deleteItem(i)">Delete</button>

And in addition the app.component.ts.

import {Component, OnInit} from '@angular/core';
import {AppService} from "./app.service";
import {FormBuilder} from "@angular/forms";

  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
export class AppComponent implements OnInit{

  ngOnInit() {
    this.form ={
      item: ''

  constructor(public appService: AppService, private fb: FormBuilder) {

  onSubmit() {

The app.component.ts creates a simple form in his ngOnInit() cycle. I do it with the FormBuilder, which I declare in the constructor next to our AppService, which I use in the onSubmit() method to add a new item. Our application now looks like following (I have added some bootstrap to make it prettier).

We can now type in the name of our new item we want to add and can add the item by clicking on the button. This will update the count on the header on the top and will also show up all items in a list in the bottom.

By clicking on the Delete button we can delete the items one by one.


Testing is essential for Software Development, because it ensure the quality of the final application. In this blog post I have demonstrated a way of testing services in Angular with Jasmine and Angular.

Thanks for reading, if you have any question, leave a comment. Also be sure to follow me on Twitter!

The Problem of Overfitting/Underfitting in Machine Learning

This blog post is part of a series, where I talk about concepts and algorithms in Machine Learning.

In this part I want to talk about Overfitting and Underfitting, which are common problems in Machine Learning which lead to low predictive models e.g. in classification problems.


Overfitting often happens when your train your model with too much data. Then the model learn from the noise and inaccurate data entries from the data set. If the model then should predict the target of the new data, it does not categorize the data correct, because there is too much noise and details. Overfitting often happens with non-parametric and non-linear methods, because this types of machine learning algorithms have more freedom in building a model based on the data set and therefore these types of algorithms can really build unrealistic models. A solution to avoid overfitting is using a linear algorithm like Support Vector Machines (SVM) if you have linear data or using parameters like the maximal depth if you are using decision trees.


In the example above we can see lines of an overfitted model an a line of a model with a regular model. The green line is from the overfitted model. It is very complex and overreacts for every point instead of just finding a moderate way like the black line from the regular model.


Underfitting is obviously the opposite of underfitting, but also can destroy the accuracy of your machine learning model. If often happens when you have to less data to build an accurate model. It also happens when you try to build a linear model with non-linear data. Then the rules of your machine learning model are to easy and flex and the model will probably guess a lot of wrong predictions. Solutions for underfitting beside getting more data is e.g. feature engineering, so e.g. reducing the features by feature selection.

Choosing the wrong parameters

Further overfitting and underfitting appears if you choosing the wrong parameters of your machine learning algorithms. As mentioned above, decision trees have e.g. the parameter max depth, which describes the max depth of the tree. If max depth is to high, overfitting will be encouraged and if max depth is to low, underfitting will be a problem.

In the next weeks I will post a blog post where I talk about concept on how you can avoid building a overfitted or underfitted machine learning model.


So overfitting and underfitting are both things you want to avoid, in the best case you want to be in the middle of them. To avoid both, be care to have enough data (there can’t be too much data, but you then have to care about choosing the right parameters and the right algorithms) and carefully evaluate your data set to choose the right decision for training.

Thanks for reading, if you have not already read my last blog post, then you can do that by clicking here. I am also active on Twitter, so if you do not want to miss any new blog posts, then follow me there.