Introduction

In the fast-paced world of software development, teams often feel continuous pressure to keep their codebases modern. Technologies evolve quickly, and developers are encouraged — sometimes expected — to update frameworks and architectures as soon as possible to avoid falling behind. But behind these expectations, sometimes not rushing ahead, rather waiting out is the better choice.

Angular has been undergoing a substantial transformation (since the version 16), leading many teams to consider gradually refactoring or rewriting parts of their applications. This shift is slow and very unusual compared to traditional Angular upgrades. Rather than introducing new features on top of the existing foundation, the core of Angular’s evolution now focuses on a new reactivity and change-detection model.

Some of Angular’s newest edition, the Signal features have already reached stability. Core state-management primitives such as signal(), computed(), effect(), and toSignal() are fully production-ready and can be used in real-world applications. However, waiting to adopt new features is not always a poor strategy.

The current situation with Signals demonstrates this well: while many signal-based APIs are stable, others — particularly Signal Forms remain experimental. For many teams, this makes a full migration premature.

Angular’s Shift in Change Detection: What It Means for Developers

Over the past few years, Angular has started to shift its change detection mechanism, moving away from the approach that relied heavily on zone.js. Previously, zone.js automatically tracked changes and, with the OnPush strategy, selectively checked components only when necessary. While this sometimes resulted in the entire component tree being checked, it formed the backbone of many widely-used Angular libraries. We are currently still using zone.js and in an interesting transition era, where the old way is still the spine of the application, but the moving away possibility already started to appear in the newer versions.

With the new approach, Angular is adopting a signal-based system—components now update only when a signal explicitly indicates that an update is needed. This change is designed to improve performance and reduce unnecessary re-renders, but it also has implications for existing libraries and patterns. Some of our most relied-upon libraries, such as the observable based RxJS and Reactive Forms, will continue to exist and function. However, as Angular transitions to this signal-based paradigm, developers may need to gradually rethink how they integrate these tools, adapting to new patterns while maintaining compatibility with legacy code.

How do we use forms without Signals?

Before the introduction of Angular Signals, developers primarily relied on Reactive Forms — a system built around classes such as FormGroup, FormControl, FormArray, and Validators. Reactive Forms provided a structured and predictable way to manage form state, apply validation rules, and react to user input. Features like tracking whether a control was touched, dirty, or valid were built-in and became standard practices in Angular applications. A key interaction pattern was subscribing to valueChanges or statusChanges observables to respond to form updates. Because these events relied on Angular’s change-detection mechanism, Reactive Forms were tightly coupled to zone.js, which handled the automatic triggering of change detection. One of the goals of Signals in modern Angular is to reduce or eliminate this dependency by providing a more explicit and fine-grained reactivity model.

Example for a Simple Reactive Form

Open in StackBlitz

Example for an Advanced Reactive form (most commonly used)

In practice, while Angular’s simple form examples are helpful, real-world applications—especially in enterprise environments—tend to rely on far more complex form structures. Instead of managing many individual controls separately, developers typically organize entire sections of related inputs under a single FormGroup (and often nested FormGroups). This “umbrella” approach makes large forms easier to manage, validate, and maintain. It also allows teams to encapsulate logic, reuse form sections, and keep the form model consistent with the structure of the underlying business domain. As a result, FormGroup-centric architectures became the standard for building sophisticated, enterprise-grade forms in Angular.

Open in StackBlitz

How do we use forms with Signals?

Example for a simple signal based form

When discussing signal-based inputs, one of the most important points to understand is that Angular’s previous Reactive Forms system was already an extremely powerful and mature tool. The shift toward Signals does not happen because Reactive Forms were inadequate or needed replacement. Instead, the move is driven by a deeper architectural change. Hence, the new Signals-based form library must compete with an already mature and battle-tested solution. In real-world scenarios, what Signals currently offer is an advanced and efficient change-detection mechanism — but one that still relies on manual validation and manual state management. As a result, the present Signals-based form approach is questionably sufficient for most production use cases. Instead of simplifying development, it often introduces additional complexity, especially when compared to the robustness and convenience of traditional Reactive Forms. Therefore, thanks to Angular’s strong commitment to backward compatibility, many teams choose to upgrade their applications to a newer version while continuing to rely on Reactive Forms for the time being. Other words: waiting out.

At the same time, it’s important to emphasize that Angular’s direction toward a Signals-based model is very promising. The foundation being built around Signal is solid, and once the form-related APIs mature, Signals are likely to provide a cleaner, more predictable, and more efficient way to handle reactivity across the entire framework.

Open in StackBlitz

Hybrid model - technically works, but no benefits, not recommended

The current problem with forms with signals is that they lacked a fully mature API to organize complex forms in a grouped structure with all the capabilities we expect (nested grouping, dynamic validation, complex logic, etc.). Although a "cheat" workaround exists — re-using the old FormGroup (from Reactive Forms) inside a signal-based setup — but relies on the legacy zone.js + observable & subscription model, which undermines many of things advantages Signals aim to deliver. As a result, using Signals with FormGroup in this hybrid way often offers little to no real benefit. Therefore, it is generally not recommended to combine them this way.

Open in StackBlitz

The advanced solution is on the way, experimental API was released.

Angular recognized this exact problem and has been working on a solution. On 19 November 2025, Angular 21 was released.

One of the most significant additions is the experimental release is Signal Forms, which address the missing feature and hopefuly be the sucessor of Reactive Forms.

Validation can be done with the newly released schemaPath. Among many nishe validation this contains the classic minLegth, maxLength, required etc. validation. The Signal Forms API is marked as experimental, meaning the API could evolve with future releases — so it is not yet recommended for production usage without caution. Based on the current version of the Signal Forms’ API, we can expect for a similarly elegant solution then Reactive Forms in the future.

Open in StackBlitz