Template-Driven Forms

The key in understanding the template-driven approach is that it still uses the same models as the model-driven approach. In the template-driven approach Angular creates the models, the FormGroups and FormControls, for us via directives we add to the template.

That’s why in this course we teach the model-driven approach first. So you’ll have a good knowledge of the underlying model structure that is still present in template-driven forms.

We create a basic form component, exactly the same as the model form component we started with in this section, with a basic form template, a dynamic select box and a simple component like so:

The directives we need to build template-driven forms are in the FormsModule not the ReactiveFormsModule, so let’s import that and add it to our NgModule as an import and remove the ReactiveFormsModule.

One of the directives pulled in via the FormsModule is called NgForm.

This directive has a selector which matches the <form> tag.

So just by adding FormsModule to our NgModule imports, our template form is already associated with an instance of the NgForm directive.

This instance of ngForm is hidden but we can expose it with a local template reference variable attached to the form element, like so:

Now we can use the variable f in our template and it will point to our instance of the ngForm directive.

One of the things the ngForm directive does is create a top-level FormGroup and lets us call functions as if it was an instance of a FormGroup.

If you remember one of the properties on a FormGroup was value, this is an object representation of all the forms controls.

So just like model-driven forms we can output that to screen simply with a pre tag and the json pipe, like so:

If you ran this code now all that would get printed out is {}. The forms value is an empty object, even if you started typing into the input fields the value would not update.

This is because the ngForm directive doesn’t automatically detect all the controls that exist inside the <form> tag it’s linked to. So although it’s created a top-level FormGroup, it’s empty.

We need go through and explicitly register each template control with the ngForm directive. ngForm will then create a FormControl instance and map that to the FormGroup.

In model-driven forms we added formControlName directives to map template form controls to existing model form controls on the component.

In template-driven forms we need Angular to create the model form controls for us for each template form control. To do that we need to do two things to each template form control:

The NgModel directive creates the FormControl instance to manage the template form control and the name attribute tells the NgModel directive what key to store that FormControl under in the parent FormGroup, like so:

is equivalent to:

After adding ngModel to our template email input control, like so:

We can also see that f.value now shows the value of the email field, like so:

If we now added the name attribute and ngModel directive to all of our template form controls we would see f.value print out:

This isn’t exactly the same as before, in our model-driven form we wanted to group firstName and lastName into a nested FormGroup called name.

We can do the same in template-driven forms with the ngModelGroup directive, let’s add that to the parent fieldset element of our firstName and lastName template form controls, like so:

We can now see that the output of f.value matches what we have before

We have now mirrored the model we created in the model-driven form using template-driven forms, with FormControls and a nested FormGroup.

Another feature of the ngModel directive is that it lets us setup two-way data binding between a template form control and a variable on our component.

So when the user changes the value in the template form control the value of the variable on the component automatically updates and when we change the variable on the component the template form control automatically updates.

The syntax for using the ngModel directive in this way is a little bit different, let’s set this up for our email field. First we add a string property called email on our component so we have somewhere to store the email, like so:

Then we setup two-way data binding by changing our email ngModel directive to:

In Angular we typically won’t data bind to a simple string or object on our component but a domain model we’ve defined via a class, let’s create one for our Signup form called Signup.

Then on our component we replace our email property with:

Now let’s bind all our input controls to our model directly, like so:

In the model-driven approach we defined the validators via code in the component.

In the template-driven approach we define the validators via directives and HTML5 attributes in our template itself, let’s add validators to our form template.

All the fields apart from the language were required, so we’ll just add the required attribute to those input fields, like so:

The email field also had a pattern validator, we can add that via an attribute as well, like so:

The password field also had a min length validator, we can add that via an attribute also, like so:

Submitting a form is exactly the same in model-driven forms as it is in template-driven forms.

We need a submit button, this is just button with a type="submit" somewhere between the opening and closing form tags.

By default this would just try to post the form to the current URL in the address bar, to hijack this process and call a function on our component instead we use the ngSubmit directive (which comes from the FormsModule).

This is an output event binding which calls a function on our component called onSubmit when the user clicks the submit button.

However, we don’t want the form submitted when the form is invalid. We can easily disable the submit button when the form is invalid, like so:

In the model-driven approach we reset the form by calling the function reset() on our myform model.

We need to do the same in our template-driven approach but we don’t have access to the underlying form model in our component. We only have access to it in our template via our local reference variable f.form

However, we can get a reference to the ngForm instance in our component code by using a ViewChild decorator which we covered in the section on components earlier on in this course.

This decorator gives us a reference in our component to something in our template.

First we create a property on our component to hold an instance of NgForm, like so:

Then we import the ViewChild decorator from @angular/core, like so:

Finally, we decorate our property with the ViewChild decorator. We pass to ViewChild the name of the local reference variable we want to link to, like so:

And then in our onSubmit() function we can just call form.reset() like we did in the model-driven approach.

The full listing for our component is now:

Now when we submit the form it blanks out all the fields and also resets the states of the form controls so any validation styling and errors reset also to the original pristine condition.

In this lecture we converted our model-driven form into a template-driven form.

We learnt that the template-driven form still uses the same classes as the model-driven form but in the template drive approach the models are created by directives in the template instead of explicitly created on the component.

The ngForm directive automatically attaches to <form> and creates a top-level FormGroup.

We learnt about the ? elvis operator and how we can use it when some properties in a dot chain can be undefined or null.

We learnt how to use the ngModel directive, how it creates FormControl instances for us, and how we can use it to implement two-way data binding to a domain model on our component.

We learnt how to use a domain model in Angular.

We learnt how to implement validation in template-driven forms as well as how to submit and reset a form.