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
(cherry picked from commit 2d85ae5811)
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`.
(cherry picked from commit 82a2de201f)
The framework will now bind the field state properties to all matching
directive inputs on form controls using Reactive Forms'
`ControlValueAccessor`.
(cherry picked from commit 15bddbdcda)
The framework will now bind the field state properties to all matching
directive inputs on custom form controls.
(cherry picked from commit 0c8f15d546)
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
(cherry picked from commit c149f47ef6)
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.
(cherry picked from commit b93d5ec27a)
The removeValidators and hasValidator methods both had identical "Reference to a ValidatorFn" section titles, causing duplicate entries in the API documentation table of contents.
(cherry picked from commit 456ca35906)
Update the typed forms guide link to point to the correct
FormArray section instead of the FormControl getting started example.
(cherry picked from commit e3781cd88a)
Adds a PURE annotation to VERSION constants, enabling tree-shaking
and keeping the implementation consistent with other pure exports.
(cherry picked from commit abb179466d)
* 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
(cherry picked from commit 1a4c3eb1d0)
There's no longer a need to test that inputs are set before
initialization on custom controls now that required inputs are
supported.
(cherry picked from commit 9ad603fa11)
* Refactor test for `disabledReasons` input to be consistent with other control
properties
* Test that `disabledReasons` inputs are reset when the field binding changes
(cherry picked from commit 4f73a350a5)
* 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
(cherry picked from commit 89c37f1f7f)
* Refactor test for `invalid` input to be consistent with other control
properties
* Test that `invalid` inputs are reset when the field binding changes
(cherry picked from commit b563b5cfc2)
* 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
(cherry picked from commit 82edf18427)
* 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
(cherry picked from commit cb09fb8308)
This better reflects the intent to indicate an error during submission,
regardless of whether the error came from the server or not.
(cherry picked from commit 244b54c9bf)
Improved documentation for Schema, SchemaFn, and SchemaOrSchemaFn types
with clearer descriptions and usage examples.
(cherry picked from commit 193aa332fc)
This will ensure that signal forms emit valid typings.
Also this commits moves `@standard-schema/spec` from peer-dep to regular dep
(cherry picked from commit 44d4439bc4)
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()
}
})
```
(cherry picked from commit 348f149e8b)
This PR makes a number of changes to the metadata API to address design
flaws in the previous API. Some of the changes include:
- Replaces the previous `MetadataKey` and `AggregateMetadataKey` with a
single unified `MetadataKey` that is used for all metadata.
- The new `MetadataKey` is only defined for fields that explicitly set
it in their schema logic
- All metadata now has reducer / aggregate behavior
- The new `MetadataKey` has an option to create a managed key which
wraps the result of its computed aggregate into some other structure
such as a `Resource` or `linkedSignal`
- There are now two APIs to create metadata keys
- `createMetadataKey` for pure computed metadata
- `createManagedMetadataKey` for metadata that manages its computation
internally
(cherry picked from commit ebc5c2b083)
FormUiControl states that hidden, pending and dirty will be bind in custom controls, but this is currently not the case.
Fixes#65575
(cherry picked from commit 9fe9566581)
This change replaces all remaining occurrences of `typeof ngDevMode !== undefined`
with the correct `typeof ngDevMode !== 'undefined'` form. This aligns the codebase
with JavaScript typeof semantics and maintains consistency with other Angular code.
(cherry picked from commit 96b79fc393)
Previously, navigating a `FieldTree` in signal forms involved reactive reads
of the value of the parent field(s), both directly and via `.childrenMap()`.
This meant that on _any_ change to the value of a field, reactive
notifications would trigger updates of computeds, reruns of effects, etc.
So for example, this effect would run on every change to the form:
```ts
const f = form(signal({data: 'abc', unrelated: 0}));
effect(() => {
// accessing f.data incurs a dependency on f().value() which changes
// on every change in the whole form
console.log(f.data().value());
});
```
This is deeply counterintuitive and troublesome when attempting to write
effect logic, and also results in `computed`s unnecessarily updating.
This change introduces the concept of a "reader" computed, which memoizes
the access of a field at a given key via the reactive graph. With this, the
same `f.data` access above now depends on the `data` reader in `f` only,
which is effectively a constant computed. As a result, the effect only
reruns on changes to `data`'s value, as intended.
PR Close#65802
Previously, several values were being passed into the creation of
`FieldNodeStructure`s that were only used in the creation of child nodes.
Separately, we also passed a `createChildNode` function which these values
were passed back into.
Instead, this moves the small bit of logic from structure.ts behind the
`createChildNode` callback, which reduces the passing of values back-and-
forth and gives `createChildNode` a much more suitable signature.
PR Close#65802
Extends the `FormUiControl` interface to allow `InputSignalWithTransform` in addition to `InputSignal` for its properties.
Fixes#65756
(cherry picked from commit 7d1e502345)
Move the instructions used to dynamically bind a `Field` directive to a
form control onto the `Field` itself. This way the instructions are only
retained if the app uses the `Field` directive.
PR Close#65599
This is necessary to exclude a race condition where the MutationObserver initialized by the instruction fired before the inputs are binded.
fixes#65678
(cherry picked from commit f35b2ef47c)
Adds a DI configuration option for signal forms that allows the
developer to specify CSS classes that should be automatically added
by the `Field` directive based on the field's status.
(cherry picked from commit c70e246c23)
The type checker will no longer prohibit binding the Signal Forms `[field]`
directive to an input with a dynamic `[attr.type]` or `[type]` binding.
(cherry picked from commit 3a1eb07c46)
Support binding `[field]` to directives that implement
`FormValueControl` or `FormCheckboxControl`.
The `[field]` binds to whichever directive (or component) matches first in the
event there are multiple implementations. We are considering whether to make
this an error state, which could be reported during type checking.
Closes#63910, Closes#64992
(cherry picked from commit f97a1d4856)
