Pushing to a `FormArray` doesn't trigger change detection

[jnizet]

Which @angular/* package(s) are the source of the bug?

forms

Is this a regression?

Yes

Description

When using zoneless change detection, pushing a new control to a FormArray does not trigger change detection.

We shouldn't have to call markForCheck() or update some signal just to cause a new control to appear in the DOM.

Please provide a link to a minimal reproduction of the bug

https://stackblitz.com/edit/stackblitz-starters-zqbvnrcq?file=src%2Fmain.ts

Please provide the exception or error you saw

Clicking the "Add control" button in the repro should cause a second input to appear, but it doesn't.

Please provide the environment you discovered this bug in (run ng version)

Angular CLI       : 21.0.0
Angular           : 21.0.0
Node.js           : 20.19.1
Package Manager   : npm 10.8.2
Operating System  : linux x64

┌───────────────────────────┬───────────────────┬───────────────────┐
│ Package                   │ Installed Version │ Requested Version │
├───────────────────────────┼───────────────────┼───────────────────┤
│ @angular/animations       │ 21.0.0            │ ^21.0.0           │
│ @angular/build            │ 21.0.0            │ ^21.0.0           │
│ @angular/cli              │ 21.0.0            │ ^21.0.0           │
│ @angular/common           │ 21.0.0            │ ^21.0.0           │
│ @angular/compiler         │ 21.0.0            │ ^21.0.0           │
│ @angular/compiler-cli     │ 21.0.0            │ ^21.0.0           │
│ @angular/core             │ 21.0.0            │ ^21.0.0           │
│ @angular/forms            │ 21.0.0            │ ^21.0.0           │
│ @angular/platform-browser │ 21.0.0            │ ^21.0.0           │
│ @angular/router           │ 21.0.0            │ ^21.0.0           │
│ rxjs                      │ 7.8.2             │ ^7.8.1            │
│ typescript                │ 5.9.3             │ ^5.9.3            │
└───────────────────────────┴───────────────────┴───────────────────┘

Anything else?

No response

[JeanMeche]

I wanna say, this is probably the same issue as #44295. Form elements don't schedule CD by themselves.

[atscott]

IIUC, it's quite literally impossible to "fix" from the callsite of push. The FormArray is part of the form model that is not linked in any way to the component/template hierarchy and there's nothing to mark for check. Templates interested in the form values and validity need to register a dependency and link that to a notification to refresh the relevant views (e.g. valueChanges.subscribe(() => this.cdr.markForCheck()).

[jnizet]

Well. The template iterates over the controls of the form array, and the controls array changes over time. So it should be a signal. That's the rule we all have to obey when writing zoneless angular code. The FormArray class should do the same to be zoneless-ready, shouldn't it?
Not saying it's easy while maintaining backward compatibility and not introducing side effects, but it should be the goal, IMHO.

[atscott]

So it should be a signal. That's the rule we all have to obey when writing zoneless angular code.
The FormArray class should do the same to be zoneless-ready, shouldn't it?
Not saying it's easy while maintaining backward compatibility and not introducing side effects, but it should be the goal, IMHO.

Attempting to shove signals into the existing system proved to be both massively breaking (eg infinite loops due to form values, validity, etc changing during template execution) and still a sub-par experience with lots of cases that just cannot work correctly. Providing an experience that partially works some of the time, in addition to breaking existing code, is not a big priority at the moment.

Providing signals in the forms APIs as a holistic experience requires a redesign from the ground up (see the new experimental signal forms in v21)

[jnizet]

Understood, thanks @atscott . At least now I know that the problem is known and that it requires manual tweaks to work.

Maybe the documentation should make it clearer, because that wasn't obvious to me (especially since I knew that signals were introduced at some point into the code of the reactive forms).

[atscott]

especially since I knew that signals were introduced at some point into the code of the reactive forms

Yea, that was the one thing I was able to land, and it was mostly only possible because it wasn’t public api. Even converting a boolean thing like isValid to a computed caused infinite loops (some explanation here #56545). Since the computed would be shared around broadly, its value would be forced to recompute multiple times during template execution, and that value is not necessarily stable. So even if in the end it flips back to the same value it was at the start of the process, it’s still seen as having changed.

Maybe the documentation should make it clearer, because that wasn't obvious to me

Agreed.

[joeskeen]

Perhaps I don't fully understand your use-case, but when I'm using signal forms with arrays and I insert into that array, I'm not doing it by calling push on that array, but rather calling update on the array signal value itself, using the spread operator to copy the array to a new instance. While I'm sure there are scenarios where your array is too large to do that, whenever you call set or update on a signal, it will trigger change detection, right?

[jnizet]

@joeskeen this is about reactive forms, not signal forms.

Calling set() or update() on a signal does not trigger CD per se. What triggers CD is modifying the value of a signal read by a template. But that doesn't have anything to do with this issue.