RFC: Strictly Typed Reactive Forms Gotchas Every Angular Developer Needs to Know
Tags: angular, forms, rfc, update
Published: 2022-05-19 19:41:23

Angular is a robust framework suitable for large codebases and enterprise applications. One significant contributing factor is Angular’s support for [TypeScript](https://www.typescriptlang.org/). Angular is built entirely in TypeScript, and because TypeScript is Angular’s primary language, Angular’s documentation treats TypeScript as a first-class citizen.

With [RFC: Strictly Typed Reactive Forms complete](https://github.com/angular/angular/discussions/44513), many expect to have strictly typed reactive forms in the upcoming Angular 14 update. After playing around with the [Strictly Typed Reactive Forms prototype](https://github.com/angular/angular/discussions/44513#user-content-prototype), I am super excited about this upcoming feature. Not only are we getting strict types for reactive forms, but we are also getting a minor feature: the `initialValueIsDefault` option for `FormControlOptions` which will allow for resetting form values back to their initial value rather than `null` by default:


![initialValueIsDefault old comparison](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/b1fckmz6ojdvwqr1jgrp.png)


![initialValueIsDefault new comparison](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3xoj7xsowewl24oey111.png)

# Strictly Typed Reactive Forms Gotchas

Strictly typed [Reactive Forms](https://angular.io/guide/reactive-forms) should be enough of a selling point to migrate to Angular 14, but it doesn’t come without flaws:

1. Reactive Forms have tricky types involving `null` and `undefined`.

2. `FormArray` generic doesn’t support Tuples.

3. `FormBuilder` syntactic sugar doesn’t infer proper generic types.

4. [Template-driven Forms](https://angular.io/guide/forms) and [Control Bindings](https://angular.io/guide/reactive-forms#adding-a-basic-form-control) mismatch underlying control type and bound `FormControl` type.

We will go over each one of these gotchas and provide explanations so you can spend less time debugging and have more time building complex forms.

# Reactive Forms Have Tricky Types Involving null and undefined

Reactive Forms having tricky types isn’t specific to the [Strictly Typed Reactive Forms update](https://github.com/angular/angular/discussions/44513), but if you’re not aware of how `null` and `undefined` play a role in Reactive Forms, you’re likely to run into [type errors](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#null-and-undefined).

`null` is a common type when considering that `FormControl` value can be `null` whenever `.reset()` is called. This is documented and explained in [RFC: Strictly Typed Reactive Forms](https://github.com/angular/angular/discussions/44513) under **Nullable Controls and Reset**. `initialValueIsDefault` option for `FormControloptions` can be used to avoid this situation by passing true. This will make the `FormControl` value non-nullable:


![Generic types example](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f75adxqc2kfj8wnimicb.gif)

Any disabled control’s value can be excluded from its `FormGroup` or `FormArray` value. In these situations, it’s easy to stumble upon undefined when expecting some nested control value. This is documented and explained in [RFC: Strictly Typed Reactive Forms](https://github.com/angular/angular/discussions/44513) under **Disabled Controls**.

And because `FormGroup` provides `.removeControl()` and `.addControl()`, you will have to explicitly mark that control’s key in the `FormGroup` as [optional](https://www.typescriptlang.org/docs/handbook/2/objects.html#optional-properties). This is documented and explained in RFC: Strictly Typed Reactive Forms under **Adding and Removing Controls**.

# FormArray generic doesn’t support Tuples

Currently, `FormArrays` are homogeneous - every control in a `FormArray` is of the same type. Attempting to use a Tuple of `FormControls` for its generic type will result in a type error:


![Tuple example](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ntzehzt4q8wnwx36guxj.gif)

Luckily the [Strictly Typed Reactive Forms update](https://github.com/angular/angular/discussions/44513) anticipates that most projects will not be 100% compatible with the update and provide a backward-compatible workaround. You can opt-out of strictly typed Reactive Forms by providing the explicit any generic to the `FormArray`. Or, in this specific situation, you can union the expected generic types for each `FormControl`:


![Tuple workaround example](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ky8jskkirj6crpntcq17.gif)

For now, we’ll have to settle for `FormArrays` with a single-typed `FormControl` array as its generic. Support for Tuple-typed `FormArrays` will likely become added in a follow-up update.

# FormBuilder Syntactic Sugar Doesn’t Infer Proper Generic Types

`FormBuilder` provides syntactic sugar that shortens creating instances of `FormControl`, `FormGroup`, or `FormArray`. Typically this reduces the amount of boilerplate needed to build complex forms. Still, since `FormBuilder` can’t infer the generic types like how `FormGroup` or `FormArray` constructor does, you end up with type errors complaining that `AbstractControl` isn’t assignable to type `FormControl`:


![FormBuilder example](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eckyf1gt277mj6o62eru.gif)

# Template-driven Forms and Control Bindings

Angular's template type checking engine will not be able to assert that the value produced by the underlying control (described by its `ControlValueAccessor`) is of the same type as the `FormControl`. This is documented and explained in [RFC: Strictly Typed Reactive Forms](https://github.com/angular/angular/discussions/44513) under **Control Bindings**.

The above restriction also applies to `NgModel` and [template-driven forms](https://angular.io/guide/forms-overview#setup-in-template-driven-forms). This is documented and explained in [RFC: Strictly Typed Reactive Forms](https://github.com/angular/angular/discussions/44513) under **Template-driven Forms**.

You won’t get a type error when binding a `FormControl` with a string value to a DOM element that has a numeric value.

This is a limitation introduced by the current template type-checking mechanism where a `FormControlDirective` which binds to a control does not have access to the type of the `ControlValueAccessor`.

# Conclusion

The [RFC: Strictly Typed Reactive Forms](https://github.com/angular/angular/discussions/44513) may not be perfect, but it’s a feature that has been [asked for since 2016](https://github.com/angular/angular/issues/13721#issue-198158565) and is highly anticipated by many seasoned Angular developers. Strict types for Reactive Forms in Angular will help developers write better code and help significantly with debugging. It will ensure better code quality, but it will provide an easier comprehension of how the [Reactive Forms API](https://angular.io/guide/reactive-forms) works in general.

Please try out the [Strictly Typed Reactive Forms prototype](https://github.com/angular/angular/discussions/44513#user-content-prototype), fork the [demo repo](https://github.com/dylhunn/typed-forms-example-app), and share your thoughts.

I've done a presentation on this topic if you want to [check it out](https://www.youtube.com/watch?v=pxqLyvIvMwY)

Want to read more blog posts by Bitovi? Check out more posts at [our blogs at Bitovi.com](https://www.bitovi.com/blog/rfc-strictly-typed-reactive-forms-gotchas-every-angular-developer-needs-to-know)