Reactive Forms in Angular

The Growing Complexity of Forms

It is hard to overstate how much form development has changed. The era of a simple HTML form followed by a server-side postback is firmly behind us. Contemporary requirements include real-time validation — checking, for instance, whether a username is already taken — as well as dynamic layouts. A registration page might let users specify how many attendees they are registering, and the form fields then appear based on that number. This kind of interface is driven by the user, almost like a role-playing game where no two players take the same path; the form adapts to each person's choices and actions. While this is a significantly better user experience, it introduces substantial complexity for the developer. Fortunately, Angular, with its "kitchen sink" philosophy, provides a robust solution for building these demanding forms: Reactive Forms.

Understanding Reactive Forms

The official documentation describes them well:

Reactive forms provide a model-driven approach to handling form inputs whose values change over time. Reactive forms are built around observable streams, where form inputs and values are provided as streams of input values, which can be accessed synchronously.

This model-driven strategy resonates deeply with me, and since I have a strong affinity for RxJS, I find myself very comfortable in this domain. A natural question arises: how does one represent this model in code, and how does that translate to the HTML rendering the controls like inputs, radios, and selects? At its core, Angular gives us the AbstractControl class (https://angular.io/api/forms/AbstractControl) as the foundational building block. The entire Reactive Forms API is constructed on top of this base class, which offers properties and methods for managing the value of your form control, along with its validation status and state (dirty, pristine, valid, invalid).

Built upon this foundation is the FormControl class (https://angular.io/api/forms/FormControl#formcontrol), which serves as the primary unit for creating a single form control. To illustrate, consider the following example.

// in your component
const firstNameControl = new FormControl({value: 'any init value or null', disabled: false},[Validators.required],[myCustomAsyncValidator])

Instantiating this class accepts three arguments: the first is a seed value or a configuration object, the second is a single synchronous validator or an array of them (the example above uses the built-in Validators.required), and the third is a single or multiple asynchronous validators. A configuration object can also be passed to specify both kinds of validators. To link this class to an HTML element, a bridge between the template and the class is needed. The Reactive Forms API provides the formControl directive for this exact purpose.

<label for="name">First Name: </label>
<input id="name" type="text" [formControl]="firstNameControl">

Rarely does a form consist of just a single control. Most forms contain multiple inputs that a user must complete. Angular, thankfully, provides FormGroup to organize controls. As the documentation states:

A form group defines a form with a fixed set of controls that you can manage together. Form group basics are discussed in this section. You can also nest form groups to create more complex forms.

Here is an example of a FormGroup.

profileForm = new FormGroup({
    firstName: new FormControl(''),
    lastName: new FormControl(''),
  });

When instantiating the FormGroup class, an object is provided where the keys are the names of our form controls, and the values are the corresponding FormControl instances. This configuration is convenient when we need to check the validity of the entire form collectively, such as requiring that all fields be completed before submission. The AbstractControl class includes a method to retrieve a child control, allowing you to query for a specific one within the group:

const firstNameControl = this.profileForm.get('firstName');

It is fair to say that AbstractControl alone could warrant an entire article; a solid understanding of it is beneficial, and the API Reference is an excellent starting point.

In the template, the formGroup directive is used to bind to the group.

<form [formGroup]="form" (ngSubmit)="onSubmit()">
      <div *ngIf="first.invalid"> Name is too short. </div>

      <input formControlName="first" placeholder="First name">
      <input formControlName="last" placeholder="Last name">

      <button type="submit">Submit</button>
   </form>

Notice that the individual controls within the group use formControlName. Since these controls are associated with a FormGroup and are not class members, formControl would not be able to locate them directly. Remember that the [] syntax in Angular signifies property binding. The formControlName directive is intelligent enough to recognize that it resides within a formGroup and will search that group for the specified control. There are also directives available to synchronize nested form types (Array, Control, Group); the API Summary can be found at https://angular.io/guide/reactive-forms#reactive-forms-api-summary.

Dynamic Forms and Form Array

Dynamic forms deliver one of the most engaging user experiences on the web. Selecting one option reveals more fields, while another choice might lead to the end of the form, making the interaction feel alive and responsive. Angular's answer to this is FormArray (https://angular.io/api/forms/FormArray). While you can also use FormGroup and add controls to it dynamically, the advantage of FormArray is that its controls do not require names. This makes it straightforward to push FormGroup instances into it, simplifying complex nesting due to methods like push, insert, and removeAt, which mirror the familiar APIs of JavaScript arrays.

Consider a registration form. The form model might be structured as follows.

registrationForm = new FormGroup({
    employees: new FormArray([this.newEmployee()])
  });

  addEmployee() {
    this.employees.push(this.newEmployee());
  }

  newEmployee() {
    return new FormGroup({
      firstname: new FormControl('', Validators.required),
      lastname: new FormControl('', Validators.required),
      jobTitle: new FormControl('', Validators.required)
    });
  }
  get employees() {
    return this.registrationForm.get('employees') as FormArray;
  }
  submit() {
    console.log(this.employees.controls[0].value);
  }

In this setup, the newEmployee method is a factory function that returns a FormGroup instance. Encapsulating this in a method is beneficial because it keeps the configuration in one place, rather than duplicating it both in the registrationForm declaration and whenever we need to add a new employee. To add a new employee at any time, this method is simply called. Additionally, the registrationForm is initialized with a FormArray that is pre-populated by invoking this method, ensuring there is at least one group ready for a new employee. A getter is also included for convenient access to the FormArray.

<form (ngSubmit)="submit()" [formGroup]="registrationForm">
  <section class="employees" formArrayName="employees">
    <ng-container *ngFor="let employee of employees.controls; let i = index;">
      <div class="employee" [formGroupName]="i">
        <input class="input"  formControlName="firstname" type="text">
        <input class="input" formControlName="lastname" type="text">
        <input class="input"  formControlName="jobTitle" type="text">
      </div>
    </ng-container>
  </section>
  <button type="submit">SUBMIT</button>
</form>
<button (click)="addEmployee()">Add Employee</button>

The markup and directives below render the form and connect it to the model. A form element is used, binding the registrationForm to it. The employees FormArray is accessed via the formArrayName directive, which is smart enough to traverse the bound object and retrieve the FormArray with that name. The array is then iterated, outputting each FormGroup. Because these controls lack names, the formGroupName directive is bound using the index of the iterated array, calculating its value dynamically. Finally, the individual controls are bound inside the formGroup using formControlName. This architecture facilitates the addition of new controls, but what about removal? The FormArray provides a removeAt method that requires the index of the item to remove. It is crucial not to modify the array used to instantiate the FormArray directly, as this can lead to unpredictable behavior.

Dynamically Managing Controls from User Input

This scenario gets particularly engaging because you're reacting to user input and executing actions based on it. At its core, it mirrors how you'd respond to click events for adding or removing controls. However, instead of subscribing to clicks, you're subscribing to user input through the valueChanges property found on the Abstract Control class. valueChanges serves as a multicasting observable that fires an event whenever the control's value changes, whether triggered by user interaction or programmatic updates. That means invoking setValue or patchValue will trigger an emission, unless you supply the {emitEvent:false} option.

So the approach here is straightforward: listen for input changes and then use the captured value to decide whether to inject or withdraw controls from the form structure.

control.valueChanges.subscribe(value => {
    if(value === 'whatever') {
        this.addNewEmployee()
    }
})

In this snippet, we're evaluating whether the value satisfies a particular condition, and when it does, we trigger a method that ultimately appends additional controls to the form array. This approach is both effective and simple, since our template is already set up to loop over the Form Array — so no further adjustments are needed on the template side. If we were instead adding a new control to the overall group, we'd reach for the addControl method. In that case, we'd also have to adjust the template to recognize a form control under that name and conditionally display those elements only when the control is actually present.