Parse errors allow a custom control to communicate that it is currently
unable to produce a valid value.
Parse errors are reported by implementing the optional `parseErrors`
property on the `FormUiControl`. The property should be a signal of the
current parse errors.
Also renames several `*Field` types to `*FieldTree`. This aligns with the new naming of the concept after `Field` was renamed
to `FieldTree`.
Previously, ng_package applied version stamping to all source files, which corrupted binary files like SQLite databases.
This change ignores text substitution for files passed to the `data` attribute, ensuring binary assets are preserved intact in the final package.
fixes#66637
Extends the `focus` method of form fields and custom controls to accept and propagate `FocusOptions`.
This enables developers to control focus behavior more precisely, for example, preventing scrolling when focusing an element.
Previously we were unconditionally setting the control value back into
the value, regardless of if it had actually been changed. This PR
changes the logic to flush the pending sync on touch if there is one, or
just skip it if there isn't.
This PR adds the ability to manually register a binding with the
`FormField` directive. This is useful for a lower-level implementation
that takes the field tree as an `input()` rather than relying on the
automatic binding from `FormUiControl`.
Prior to this change, binding to radio value was sensitive to the order in which `value` & `formField` where binding in the template.
The compiler change makes that order non-important.
fixes#66402
Add comprehensive test cases to validate behavior when multiple
pattern validators are applied to the same field.
These tests clarify that multiple patterns operate with AND logic,
where each pattern is validated independently and produces its own
error when it doesn't match.
Error message links now point to the archived documentation site (v*.angular.dev)
so that referenced content matches the framework version in use.
See angular#44650
PR Close#66374
This completes the rename started in #66136. `[field]` is too generic of
a selector for the forms system to own, and likely to cause naming
collisions with existing components. Therefore it is being renamed to
`[formField]`
Remove the `customError` function and `CustomValidationError` type.
These were made obsolete by support for returning plain object literals
as custom errors.
This also catches few `field` properties that were missed in the
renaming to `fieldTree`.
Removes the abort event listener once the debounce timeout completes.
This avoids lingering listeners, prevents potential memory leaks, and ensures
the abort logic runs at most once.
This will replace the `[field]` directive, since `[field]` is a very
generic name for signal forms to commandeer
refactor(forms): hook up `formField` directive in compiler
Hooks up the `formField` direcive to get the same treatment as the
`field` directive in the compiler.
apply updated formatting
The framework will now bind all field state properties to their
corresponding native properties (if any) on interop form controls (those
using `ControlValueAccessor`), excluding those handled explicitly by
`ControlValueAccessor` such as `disabled`.
Since the `Field` directive manages binding `FieldState` properties to
the underlying form control automatically, the type checker prohibits
explicit bindings to the same properties to avoid conflicts. This proved
problematic in cases where developers wanted to bind these properties to
the inputs of other directives on form controls. Now the framework will
bind the field state properties to all matching directive inputs on
native controls.
Fix#65617
Add @see JSDoc tags to Signal Forms API functions and classes to link to the essentials guide and detailed documentation pages. This improves discoverability of Signal Forms documentation from the API reference.
The removeValidators and hasValidator methods both had identical "Reference to a ValidatorFn" section titles, causing duplicate entries in the API documentation table of contents.
This commit introduces the infrastructure for embedding code examples within Angular packages, enabling them to be consumed by the Angular CLI's MCP server.
The `@angular/forms` package is the first to adopt this new feature. A new `ng_examples_db` Bazel rule is used to build a SQLite database from markdown files containing code examples. This database is then included in the published npm package.
The `package.json` for `@angular/forms` has been updated with an `angular.examples` field to allow tooling to discover and use the code examples.
* Allow custom controls to make `pending` a required input
* Refactor test for `pending` input to be consistent with other control
properties
* Test that `pending` inputs are reset when the field binding changes
* Refactor test for `disabledReasons` input to be consistent with other control
properties
* Test that `disabledReasons` inputs are reset when the field binding changes
* Allow custom controls to make `dirty` a required input
* Refactor test for `dirty` input to be consistent with other control
properties
* Test that `dirty` inputs are reset when the field binding changes
* Refactor test for `invalid` input to be consistent with other control
properties
* Test that `invalid` inputs are reset when the field binding changes
* Allow custom controls to make `hidden` a required input
* Refactor test for `hidden` input to be consistent with other control
properties
* Test that `hidden` inputs are reset when the field binding changes
* Recognize directives with non signal-based models as valid custom controls
* Relax type checker to allow non signal-based models
The `FormValueControl` and `FormCheckboxControl` interfaces still
require a `model()`-input, however, a custom control need not implement
either interface to be bound by the `Field` directive.
All of the following examples can be used to define a custom control:
```ts
// Preferred: model()
class MyFormControl implements FormValueControl<string> {
readonly value: model.required<string>();
}
// Supported: input() + output()
class MyFormControl {
readonly value: input.required<string>();
readonly valueChange: output<string>();
}
// Supported: @Input() + @Output()
class MyFormControl {
@Input({required: true}) value!: string;
@Output() valueChange: new EventEmitter<string>();
}
```
The latter two may still choose to implement `FormUiControl` for other
properties, but again it is not required.
Fix#65478
Updates signal forms to pass the full `Field` directive to the class
configuration functions, rather than just the state. This allows
developers to take the element as well as the state into consideration
when deciding classes to apply.
Closes#65762
BREAKING CHANGE: The shape of `SignalFormsConfig.classes` has changed
Previously each function in the `classes` map took a `FieldState`. Now
it takes a `Field` directive.
For example if you previously had:
```
provideSignalFormsConfig({
classes: {
'my-valid': (state) => state.valid()
}
})
```
You would need to update to:
```
provideSignalFormsConfig({
classes: {
'my-valid': ({state}) => state().valid()
}
})
```
