Drawing on our on-the-ground experience with Angular Typed Forms, we present a thorough guide coupled with best practices, enabling you to make the most of Angular’s stellar feature in your everyday projects.

Angular Typed Forms, one of the more recent and certainly the most significant enhancements to the Reactive Forms API, enable you to – add types to your Angular forms. 

Initially introduced as a developer preview in Angular 14, Angular Typed Forms have been deemed stable as of Angular 15. This particular form type helps us catch errors early in development, enhances code readability and maintainability, and supports useful features like auto-completion. 

The feature, which was the top-requested enhancement for several years, was finally implemented by the Angular team in response to community feedback. As Angular Typed Forms have matured, our team at Infinum has accumulated ample practical experience in their use. In this article, we aim to share what we have learned and bring you practical recommendations and proven best practices so you can make the most of Angular’s prized feature. 

The main goal of typed forms is to maximize type safety and enhance the developer experience in creating Reactive Forms. The Angular team wanted to support their gradual adoption, so they enabled the use of both typed and untyped forms to prevent disrupting existing applications.

Angular Typed Forms are not designed to support template-driven forms or non-model classes such as validators. They are also not intended to alter the underlying functionality of forms; all current form APIs remain the same.

Let’s explore how FormGroup and FormControl, key components of Angular’s reactive forms, are used in versions before Angular 14 and in version 14 and beyond.

Consider the following simple code using FormGroup with one FormControl:

In versions preceding Angular 14, you could write this kind of code without knowing if the control exists inside the FormGroup. This example is obvious, but it could have easily happened that you made a tiny typo and spent quite a lot of time debugging. 

With typed forms, you get the following error:

On top of getting an error message, you are less likely to make this type of error in the first place because the autocomplete feature will give you a list of all of the controls.

Another big improvement Angular Typed Forms brings is in the usage of FormControl values. 

Let’s say a child component has an input that accepts a value of some type; for example, string, and we want to pass our FormControl value. 

In this example, you might get runtime errors but won’t get build-time errors, even though we passed a boolean value to a string input. In the Angular versions below 14, all FormControl values are typed as any.

This is what happens with typed forms:

We get a pretty obvious TypeScript error, which is a huge win.

In Angular 14 and beyond, form controls are typed by default. You don’t have to do anything special to create your first typed FormControl.

The type resulting from the above control is FormControl<string | null>. Angular automatically infers the control type from the initial value.

What if our control value can be of multiple types, for example, a number and a string? In this case, Angular cannot know all the possible value types, so we need to supply them as a Typescript generic argument to FormControl.

Now, why does null appear in the list if we said the FormControl type is either string or number?

Every typed FormControl can be null by default, i.e., they are nullable. This happens because every FormControl can be reset, and if you call the .reset() method, it will set the value to null, so the type is indeed correct. However, if this is not a desired behavior for your use case, you can change it by passing a nonNullable flag as an option to FormControl. With the flag set to true, the FormControl will reset to the initial value instead of null.

What if you do not supply the initial value and a generic argument?

The resulting type will be FormControl<any>. This is because we didn’t supply any type information or initial value to FormControl, and Angular can’t infer it.

In most cases, Angular will infer the type of FormControl correctly by default. We prefer this approach over stating the types explicitly unless we really need them.

The inferred FormArray type will be the result of all its inner control types. If you want to have different types of controls inside the array, you must use UntypedFormArray. They are created in the same way, and everything said in the FormControl section applies to FormArray as well.

FormGroup behaves the same as in previous Angular versions, the only exception being the difference between value and rawValue explained later on.

Note: It is possible to mix and match typed and untyped form controls in the typed FormGroup.

FormBuilder also got an upgrade in the form of typed support. All the rules explained above apply to FormBuilder as well. If you want to create a form with all the controls set as non-nullable, just use the NonNullableFormBuilder.

Angular has no built-in utility type for inferring the type of value property nor a getRawValue method. Because we needed one of those, we created a utility type that you can also use. The helpers are part of the ngx-nuts-and-bolts package on the NPM.

To extract a form value or a raw value as a type and use it in multiple places within a project, we need to follow two simple steps.

The types we just created can now be used for typing function arguments, nested form groups, etc.

Notice how in the case of a form we also get undefined as a possible type. This is because every control can be disabled, which brings us to the explanation. Disabled form controls won’t be included in the resulting object when you call .value on a control. Should you wish to always get the value of a control, use .getRawValue() instead. The choice what route to take here will depend on your specific use case.

Refactoring your Angular forms is optional and will depend on many factors, such as the size of your projects, the complexity and number of forms used, and your team or company’s strategic direction. Refactoring a project that has only one form is not very hard, but multiple ones can present a problem. However, in most scenarios, the refactoring is worth the effort. Don’t be surprised if you end up discovering bugs that you never knew existed before.

As we often recommend, it’s best to refactor parts of code when you are already modifying it in the course of new development or bug-fixing. The next time you update a form, consider upgrading at least a part of it to utilize typed forms.

Angular Typed forms are fully backward compatible, which means you can update your Angular version without fear you’ll need to refactor your existing application extensively. Upon updating to Angular 14, all your forms will be automatically migrated to their respective untyped versions. FormControl becomes UntypedFormControl and so on.

One of the limitations of Angular Typed Forms is that the Typed Forms API doesn’t work with template-driven forms. If you are working on an older project with many template-driven forms you won’t be able to enjoy these new benefits.

Our recommendation is to always aim to bind form controls directly in the template using formControl instead of formControlName. This will enable you to catch errors as early as possible or not even make them in the first place. 

Using this approach, you’ll be thrown an error if you try to access a control that does not exist, and you will also benefit from the auto-complete function, which further reduces the chance of making an error. Additionally, you protect yourself for the case of future changes because renaming or deleting a FormControl will result in an error in the template.

The same recommendation applies for accessing form controls in components. Avoid using get to catch errors earlier in the development process.

Type-safe forms in Angular represent one of the most significant changes in recent Angular history. They don’t require an immediate refactor of your entire codebase, and the migration process is straightforward. In addition, they enhance the developer experience by eliminating the possibility of accessing non-existent attributes or assigning unsupported values to form controls. 

In fact, there’s hardly a downside to typed forms. They also prevent many bugs while improving maintainability throughout the project’s lifecycle. Based on experience and the knowledge we’ve attained so far, we’d definitely recommend using Angular Typed Forms on all new projects by default, as well as adopting them in existing ones when creating new forms. As always, we look forward to new additions and improvements to the framework and can only say – always bet on Angular.

Angular Signals – a feature introduced in Angular 16 brings a new way of handling reactivity in applications. We discover what they are, how they work, how they interoperate with RxJS, and what revolutionary changes they bring.

The release of Angular v16 brought a very important feature many developers are already calling the framework’s renaissance – Angular Signals.

Personally, I wouldn’t say Angular ever fell out of favor, and NPM downloads don’t necessarily reflect if a framework is good or bad. However, one thing we can agree on is that it has a steeper learning curve compared to, say, React.

With Signals, this is bound to change because you no longer need complex patterns to start writing performant Angular code. Angular Signals make the platform more approachable to beginners, and in that sense, it does mark the beginning of a completely new phase.

The Angular team’s motivation for introducing this feature was adding fine-grained reactivity into the framework. This concept is fundamentally different from how Angular functions today, where zone.js is used to trigger global change detection for the whole application. The changes introduced will allow:

First of all, signals’ values are synchronous and always available. How many times did you want to get a simple value from an RxJS chain but had to go through all the hassle of subscribing and unsubscribing to read it? Here are some more upsides to using signals.

Signals are a system that allows Angular to granularly track where a state is used and updated in the application, which then allows the framework to optimize the application’s rendering.

In signals, consumers are any part of the code that uses a signal’s value and wants to be notified about a change in that value. When a change occurs, the signal notifies all the consumers, which then act upon the change in the signal’s value.

A signal can contain any value. It can be either read-only or writable, and it can be called anywhere in the code. Let’s say you define a signal in a service. You can then use it in a template, component, pipe, or even other services. A signal value is reactive.

Signals are available as of Angular version 16 as a developer preview, which allows you to experiment with them. Even though the majority of the API is stable and functional, this is a major change, so you can expect bugs, and the API is still subject to change.

We would recommend avoiding using Signals in production projects until they are 100% stable, and expect this to happen in Angular version 17. The developer preview only lists a basic subset of the API, while the inputs, outputs, etc., are announced for v17+.

You can create a new signal by calling a signal() function and passing in an argument that contains its initial value. Think of it as BehaviorSubject in the RxJS, but without the subscribe part.

The method asReadonly() will return a signal that is non-writeable. You can access its value, but it does not allow changing the signal.

To set or change the value of a signal programmatically, call the set() method.

If a new state is derived from an old one, use the update() method where the first argument of the callback function is the previous state of the signal. You can then use it to calculate the new state.

When working with arrays or objects, use the mutate() method to trigger updates. This is very useful because mutating a signal that contains an object will trigger change detection, whereas using a conventional approach wouldn’t because the object reference would remain the same. Before signals, you would either have to create a new array or object or call change detection manually.

Computed signals derive their value based on one or more other signals. Whenever one of those signals changes, the computed signal also changes.

It’s important to note that computed values are cached, meaning that every future read of that computed signal will return cached values instead of recalculating them, until the signals computed depend on the changes. You can think of them as pure pipes where the transform() function won’t run until the value changes. Computed signals take a derivation function to calculate value, and it is not possible to programmatically set the value using set or mutate methods. The dependencies inside the computed signals are dynamic, which means if you have some expensive nested signal computations, only the ones read during computations will be executed.

There’s another important note here – anything derived from a signal is also a signal.

The effect function is used for triggering side effects when one or more signals inside it change. Every effect function will run at least once, and every signal that has been called inside it becomes tracked. If any of those signals change, the effect function will execute again.

Use the effect function wisely and don’t use it to propagate state changes, as you can unintentionally introduce circular references or change detection cycles. An effect can only be called inside of the injection context, similar to the inject API. Meaning you cannot register an effect inside of a function call, for example.

Effects automatically destroy when the context they were created in (component/service) gets destroyed or they can be removed manually using the destroy method. Always make sure to destroy an effect, similar to how you would handle subscriptions in an app, or you risk memory leaks.

The introduction of signals doesn’t mean that the Angular team is abandoning RxJS. In fact, they will make RxJS integration easier.

While signals are great for handling synchronous reactivity, they are not a good out-of-the-box solution for asynchronous reactivity (think API calls). The reason for this is that signals are synchronous and will set the value that came in last. For example, since the time of API calls varies, it may happen that a wrong value is set. However, you can transform an observable into a signal by calling toSignal() or vice versa by calling toObservable().

The toSignal function internally subscribes to the given Observable and updates the returned signal any time the Observable emits a value. This subscription is created immediately as opposed to waiting until the signal is read.

The signature of the toSignal function supports both synchronous and asynchronous Observables. Angular Signals always need to have an initial value. In case one is not provided, the signal value remains undefined until an Observable emits the first value. This is useful if the Observable turned to signal is, for example, an API call.

The unsubscribe part is the same as the effect when the context in which the signal has been created is destroyed.

toObservable is a function that takes an Angular Signals and returns an Observable. It does this by creating an effect under the hood when the Observable is subscribed to. This effect takes values from the signal and streams them to subscribers. All values are asynchronous. The function toObservable must be called in an injection context.

Over the years, Angular developers have learned to avoid calling functions inside templates because a function re-runs every change detection and used pure pipes instead. This would cause expensive computations to run multiple times unnecessarily if the passed arguments did not change.

In a signal-based component, this idea no longer applies because the expressions will only re-evaluate as a result of a signal dependency change.

With signals, we no longer have to care about handling subscriptions. It is absolutely fine to call a signal function in the template since only the part that depends on that signal will be updated.

During the signals’ RFC phase, the Angular team proposed a set of new APIs. These are not available in the developer preview of Angular version 16 but should become so in future versions. Since those APIs are still in the works, only basic descriptions are given.

To mark a component as signal-based, you have to set the property of the signal in the component decorator to true. Given that most newly generated components in newer projects will be signal-based and standalone, the Angular team is working on a solution to mark components as both standalone and signal-based by default when generating new components to reduce the boilerplate.

Traditional zone-based components have eight different lifecycle methods, but since they are tightly coupled with the current Angular change detection model, they are redundant when using signals.

In signal-based components, only ngOnInit and ngOnDestroy exist from the original lifecycle methods, while three new ones are proposed to be added to supplement signal-based components. These should include afterNextRender, afterRender, and afterRenderEffect.

In signal-based components, all component inputs are proposed to be signals. This means you should be able to use them as regular read-only signals out of the box. Unlike traditional inputs, signal inputs are not decorators!

Angular Signals do not affect traditional outputs, but in order to be consistent with inputs API, a new output function will be introduced with a syntax similar to the inputs.

Signal-based components additionally have access to a new type of input, model inputs. This creates an input-output binding between parent and child components. The syntax proposed is banana in a box, similar to the ngModel.

The introduction of Angular Signals is not just another Angular rewrite like the move from AngularJS to Angular 2. It is an additive change, a gradual change, and it’s completely backward-compatible.

Signals don’t mean that you can throw everything you know out the window immediately. They work on a full opt-in basis. You can refactor, use them only in the new features you develop, mix and match with RxJS or simply continue to use RxJS. All of your RxJS knowledge is still relevant. No approach is wrong here, and it is completely up to you or your team to decide which one to take.

That being said, the logical next step would probably be to try signals out and use them on newer features or features built from scratch and just take it from there.

Overall, signals are a huge change and a major leap forward for Angular.

Signals will substitute many RxJS patterns, which, although very logical once you get the hang of them, have a steep learning curve for beginners, which tends to put people off.

We believe Angular is a great choice for projects as it is very stable, performant, comes with almost all of the features you will need out-of-the-box and is now easier to get started with than ever before. As signals are currently in development preview, consider this blog post a mere Part 1.

Time, experience, and practical usage will reveal the best practices and patterns for signals. Always bet on Angular.