Commit graph

5 commits

Author SHA1 Message Date
kirjs
b60d5e49b1 refactor(forms): get rid of watFor in validation status spec (#63948)
It was flaky, and now it is not flaky

PR Close #63948
2025-09-19 17:59:32 +00:00
SkyZeroZx
d201cd2c2b feat(forms): Prevents marking fields as touched/dirty when state is hidden/readonly/disabled (#63633)
Ensures fields that are hidden, disabled, or readonly cannot be marked as touched or dirty, improving form state integrity

PR Close #63633
2025-09-15 16:52:15 +00:00
Miles Malerba
00a1806eaa refactor(forms): add validateStandardSchema to public api (#63616)
Add `validateStandardSchema` which was accidentally omitted from the
public api.

PR Close #63616
2025-09-08 13:58:55 -07:00
Miles Malerba
10ef96adb3 fix(forms): consistent treatment of empty (#63456)
Removes custom handling of emptiness in several of the validators and
replaces it with a common `isEmpty` check. The common empty check
considered the following values to be empty: `null`, `undefined`, `''`,
`false`, `NaN`

Generally most validators should treat an empty value as valid. This
aligns with both the behavior or native HTML validators and reactive
forms validators.

As an example, consider an optional email field. If the email validator
considered empty string to be an invalid email, there would be no way
for the user to not enter it.

There are several exceptions to this rule:
- `required` whose entire purpose is to ensure that the field is *not*
  empty
- `validateStandardSchema` which should subject all values including
  empty ones to the specified standard schema. It is up to the schema to
  decide whether an empty value is valid or not
- `validate`/`validateAsync` which leaves it up to the user's custom
  validation logic to decide if an empty value is valid.

PR Close #63456
2025-08-29 14:43:03 -07:00
Miles Malerba
b8314bd340 feat(forms): add experimental signal-based forms (#63408)
This commit introduces an experimental version of a new signal-based forms API for Angular. This new API aims to explore how signals can be leveraged to create a more declarative, intuitive, and reactive way of handling forms.

The primary goals of this new signal-based approach are:

*   **Signal-centric Design:** Place signals at the core of the forms experience, enabling a truly reactive programming model for form state and logic.
*   **Declarative Logic:** Allow developers to define form behavior, such as validation and conditional fields, declaratively using TypeScript. This moves logic out of the template and into a typed, testable schema.
*   **Developer-Owned Data Model:** The library does not maintain a copy of data in a form model, but instead read and write it via a developer-provided `WritableSignal`, eliminating the need for applications to synchronize their data with the form system.
*   **Interoperability:** A key design goal is seamless interoperability with existing reactive forms, allowing for incremental adoption.
*   **Bridging Template and Reactive Forms:** This exploration hopes to close the gap between template and reactive forms, offering a unified and more powerful approach that combines the best aspects of both.

This initial version of the experimental API includes the core building blocks, such as the `form()` function, `Field` and `FieldState` objects, and a `[control]` directive for binding to UI elements. It also introduces a schema-based system for defining validation, conditional logic, and other form behaviors.

Note: This is an early, experimental API. It is not yet complete and is subject to change based on feedback and further exploration.

Co-authored-by: Kirill Cherkashin <kirts@google.com>
Co-authored-by: Alex Rickabaugh <alxhub@users.noreply.github.com>
Co-authored-by: Leon Senft <leonsenft@users.noreply.github.com>
Co-authored-by: Dylan Hunn <dylhunn@gmail.com>
Co-authored-by: Michael Small <michael-small@users.noreply.github.com>

PR Close #63408
2025-08-28 09:02:43 -07:00