{"id":31238,"date":"2026-01-22T21:00:49","date_gmt":"2026-01-22T20:00:49","guid":{"rendered":"https:\/\/www.angulararchitects.io\/blog\/all-about-angulars-new-signal-forms\/"},"modified":"2026-02-14T13:24:37","modified_gmt":"2026-02-14T12:24:37","slug":"all-about-angulars-new-signal-forms","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/","title":{"rendered":"Angular Signal Forms – Everything You Need to Know"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 2 of 3 in the series “Signal Forms”<\/em>\t\t<\/p>\n\t\t\t<\/label>\n\n\t\t\t

\n\t\t\t
    \n\t\t\t\t\t\t\t\t\t
  1. Dynamic Forms: Building a Form Generator with Signal Forms<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  2. Angular Signal Forms – Everything You Need to Know<\/span><\/li>\n\t\t\t\t\t\t\t\t\t
  3. Migrating to Angular Signal Forms: Interop with Reactive Forms<\/a><\/li>\n\t\t\t\t\t\t\t<\/ol>\n\t\t<\/div>\n\t<\/div>\n

    The long-awaited Signal Forms bridge a crucial gap between Angular's Signal-based reactivity and user interaction. While currently experimental and intended to gather initial feedback, they show the direction Angular is heading.<\/p>\n

    In this article, I'll go into the details of this new library. In addition to the basics, I'll discuss more advanced aspects such as the many types of custom validators, conditional validation, subforms, and custom controls.<\/p>\n

    Table of Contents<\/strong><\/p>\n

      \n
    1. Creating a Signal Form<\/a> <\/li>\n
    2. Understanding the FieldTree Type<\/a><\/li>\n
    3. Signal Form Schemas<\/a> <\/li>\n
    4. Field Validation<\/a>: Custom<\/a>, Conditional<\/a>, Cross-Field<\/a>, Async<\/a><\/li>\n
    5. Nested Forms and Form Arrays<\/a> <\/li>\n
    6. Form Metadata<\/a> <\/li>\n
    7. Null and Undefined Values<\/a><\/li>\n
    8. Creating Custom Fields<\/a> <\/li>\n<\/ol>\n

      Creating a Signal Form <\/span><\/h2>\n

      To get started, we create a first form for the flight itself. In later sections, we will extend it to include nested forms for the connected airplane and the prices:<\/p>\n

      \"The<\/p>\n

      Setting up the Component<\/h3>\n

      Our implementation receives the flight to be displayed from a service named FlightDetailStore<\/code>. To set up our Signal Form, we pass this flight to the form<\/code> function provided by Angular's Signal Forms package :<\/p>\n

      \/\/ src\/app\/domains\/ticketing\/feature-booking\/flight-edit\/flight-edit.ts\n\nimport { linkedSignal } from '@angular\/core';\nimport { form, minLength, required } from '@angular\/forms\/signals';\n[...]\n\n@Component([...])\nexport class FlightEditComponent {\n  private readonly store = inject(FlightDetailStore);\n\n  protected readonly flight = linkedSignal(() => this.store.flightValue());\n\n  \/\/ Set up the Signal Form with validation rules\n  protected readonly flightForm = form(this.flight, (path) => {\n    required(path.from);\n    required(path.to);\n    required(path.date);\n\n    minLength(path.from, 3);\n  });\n\n  [...]\n}<\/code><\/pre>\n
      As the service returns a readonly signal, we use linkedSignal<\/code> to convert it in a writable one. This is important because Signal Forms writes back the modifications performed by the user.<\/p>\n
      The second parameter form<\/code> gets passed is a schema with validation rules. Angular provides the required<\/code> and minLength<\/code> rules out of the box. Further simple validators that ship with Signal Forms include maxLength<\/code>, min<\/code>, max<\/code>, and pattern<\/code>. The latter checks against a regular expression.<\/p>\n
      The path<\/code> parameter of type SchemaPathTree<\/code> is used to point to the individual properties we want to validate, e.g., from<\/code> or to<\/code>.<\/p>\n
      As a result, form<\/code> returns a FieldTree<\/code> that allows to bind the individual properties of the flight to form controls in the template. We'll discuss this imporant data structure in the next section.<\/p>\n
      Understanding the FieldTree Type <\/span><\/h3>\n
      You can think about a FieldTree<\/code> as a deeply nested Signal. Each property in the data structure is represented by a Signal with form state, e.g. value<\/code>, dirty<\/code>, invalid<\/code>. Because these properties are Signal-based, we can bind them to form controls.<\/p>\n
      For instance, let's imagine the flight<\/code> we pass to the function form<\/code> looks like this:<\/p>\n
      {\n  id: 1,\n  from: 'Graz',\n  to: 'Hamburg',\n  date: '2030-12-24T17:30',\n  delayed: false,\n  delay: 0,\n  aircraft: { \n    type: 'T0815', \n    registration: 'R4711' \n  },\n  prices: [\n    { flightClass: 'economy', amount: 299 },\n    { flightClass: 'business', amount: 599 },\n  ]\n}<\/code><\/pre>\n
      In this case, the FieldTree<\/code> returned by the form<\/code> provides Signals for each property:<\/p>\n
      const date = flightForm.date().value(); \nconst isDateDirty = flightForm.date().dirty();\nconst isDateInvalid = flightForm.date().invalid();\nconst dateErrors = flightForm.date().errors();<\/code><\/pre>\n
      Here, the date<\/code> itself is a signal and value<\/code>, dirty<\/code>, invalid<\/code>, and errors<\/code> are as well. The property dirty<\/code> is true<\/code> when the user modified the value and invalid<\/code> is true<\/code> when there was a validation error. <\/p>\n
      The errors<\/code> property contains an array with all detected validation errors. For instance, our schema set up in the previous section requires from<\/code> to be set. If this is not the case, this violation is reported by an object in the errors<\/code> array. To get a better feeling for it, we'll display this array with the JsonPipe<\/code>.<\/p>\n
      As the FieldTree<\/code> is nested, we can also access the properties at deeper levels, such as the airplane's type or the prices:<\/p>\n
      const aircraftType = flightForm.aircraft.type().value();\nconst isAircraftTypeDirty = flightForm.aircraft.type().dirty();\nconst isAircraftTypeInvalid = flightForm.aircraft.type().invalid();\nconst aircraftTypeErrors = flightForm.aircraft.type().errors();\n\nconst firstPriceAmount = this.flightForm.prices[0].amount().value();\nconst isFirstPriceAmountDirty = this.flightForm.prices[0].amount().dirty();\nconst isFirstPriceAmountInvalid = this.flightForm.prices[0].amount().invalid();\nconst firstPriceAmountErrors = this.flightForm.prices[0].amount().errors();<\/code><\/pre>\n
      For our example that means that we can bind the properties of the flight itself but also the properties of the connected airplane and the connected prices. The next section is already binding some properties to the template.<\/p>\n
      Binding to the Template<\/h3>\n
      For binding parts of the Signal Form to the template, we need to import the FormField<\/code> directive. For easily displaying validation errors during our first steps, we also import the JsonPipe<\/code>:<\/p>\n
      \/\/ src\/app\/domains\/ticketing\/feature-booking\/flight-edit\/flight-edit.ts\n\n[...]\n\nimport { JsonPipe } from '@angular\/common';\n\nimport {\n  form,\n  FormField,\n  minLength,\n  required,\n} from '@angular\/forms\/signals';\n\n@Component({\n  selector: 'app-flight-edit',\n  imports: [\n    [...]\n\n    \/\/ Import FormField directive\n    FormField,\n\n    \/\/ Add JsonPipe \n    JsonPipe,\n  ],\n  templateUrl: '.\/flight-edit.html',\n  changeDetection: ChangeDetectionStrategy.OnPush,\n})\nexport class FlightEditComponent {\n  [...]\n}<\/code><\/pre>\n
      This directive can be used to bind individual fields of our FieldTree<\/code> to form controls such as input<\/code> or select<\/code> but also to custom controls implemented with Angular as we will see at the end of this article.<\/p>\n
      For now, let's just bind some properties of our flight<\/code> to input fields:<\/p>\n
      <!-- ...\/ticketing\/feature-booking\/flight-edit\/flight-form\/flight-form.html -->\n\n@let flightForm = flight();\n\n<fieldset>\n  <legend>Flight<\/legend>\n\n  <div class="form-group">\n    <label for="flight-id">ID<\/label>\n    <input\n      class="form-control"\n      [formField]="flightForm.id"\n      type="number"\n      id="flight-id"\n    \/>\n  <\/div>\n\n  <div class="form-group">\n    <label for="flight-from">From<\/label>\n    <input\n      class="form-control"\n      [formField]="flightForm.from"\n      id="flight-from"\n    \/>\n    @if (flightForm.id().invalid()) {\n      <div>{{ flightForm.id().errors() | json }}<\/div>\n    }    \n  <\/div>\n  [\u2026]\n<\/fieldset><\/code><\/pre>\n
      Please note that when binding a number you need to use an <input type="number" ...><\/code> because Signal Forms also respects HTML semantics when ensuring type safety.<\/p>\n
      Behind errors<\/code> is an array containing all validation errors detected for the field, which the component outputs for illustrative purposes. The following screenshot shows this array in a case where the minLength<\/code> validator was triggered:<\/p>\n
      <\/p>\n
      However, the minLength<\/code> validator isn't triggered for empty fields. This common approach supports optional fields. However, if the field isn't optional, a required<\/code> validator handles the empty field.<\/p>\n
      Submitting  <\/span><\/h3>\n
      In general, you don't need any special function to submit a form. You can simply read the form's value and pass it to a service or store. However, the submit<\/code> function provided by Signal Forms offers additional benefits:<\/p>\n
      \/\/ src\/app\/domains\/ticketing\/feature-booking\/flight-edit\/flight-edit.ts\n\n[...]\n\n\/\/ Add submit\nimport {\n  form,\n  FormField,\n  minLength,\n  required,\n  submit,\n} from '@angular\/forms\/signals';\n\n[...]\n\n@Component({\n  [...]\n})\nexport class FlightEditComponent {\n\n  [...]\n\n  protected readonly flightForm = form(this.flight, [...]);\n\n  [...]\n\n  protected async save(): Promise<void> {\n    await submit(this.flightForm, async (form) => {\n      try {\n        await this.store.saveFlight(form().value());\n        return null;\n      } catch (error) {\n        return {\n          kind: "processing_error",\n          error: String(error),\n        };\n      }\n    });\n  }\n}<\/code><\/pre>\n
      The submit<\/code> function accepts both a signal form and an action to be executed. The latter is only executed if there are no validation errors. If an error occurs during saving, this action can return a ValidationError<\/code>. Alternatively, it could return an array containing multiple ValidationError<\/code> objects.<\/p>\n
      The function submit<\/code> adds these errors in the Signal Form. Hence, they can be displayed like any other validation errors by presenting the form element's errors<\/code> array.<\/p>\n
      NOTE<\/p>\n
      Modern Angular<\/h3>\n
      This article is extracted from my new book Modern Angular - Architecture, Concepts, Implementation<\/a>. This book covers everything you need for building modern business applications with Angular: from Signals and state patterns to architecture, AI assistants, testing, and practical solutions for real-world projects.<\/p>\n
      \"Modern<\/a><\/p>\n
      Learn more about the book \u2192<\/a>\n<\/div>\n<\/p>\n
      Schemas \u2014 How They Work? <\/span><\/h2>\n
      The schema passed to the form<\/em> function defines not only validation rules but also other aspects of the form's behavior. For instance, a schema could specify that changes are debounced or that some fields are read-only under certain conditions. In this section, I'll discuss these aspects in more detail.<\/p>\n
      Splitting Schemas for Maintainability <\/span><\/h3>\n
      So far, the schema has been defined directly in the call to the form<\/code> function. However, for larger schemas this approach quickly becomes unwieldy. To make the individual components clearer, the schema can be refactored to a separate constant in a separate file. Since the schema defines general rules, it can be placed in the data<\/code> folder.<\/p>\n
      \/\/ src\/app\/domains\/ticketing\/data\/flight-schema.ts\n\nimport { required, minLength, schema } from "@angular\/forms\/signals";\n\nimport { Flight } from ".\/flight";\n\nexport const flightSchema = schema<Flight>((path) => {\n  required(path.from);\n  required(path.to);\n  required(path.date);\n\n  minLength(path.from, 3);\n});<\/code><\/pre>\n
      The call to the function form<\/code> can then refer to it:<\/p>\n
      \/\/ src\/app\/domains\/ticketing\/feature-booking\/flight-edit\/flight-edit.ts\n\n[...]\n\nprotected readonly flightForm = form(this.flight, flightSchema);\n\n[...]<\/code><\/pre>\n
      Schemas can also reference each other. This is useful, for example, if a form adds some specific validation rules to a schema with general ones:<\/p>\n
      import {\n  apply,\n  minLength,\n  required,\n  schema,\n} from '@angular\/forms\/signals';\n\nimport { flightSchema } from '..\/..\/data\/flight-schema';\n\nexport const flightFormSchema = schema<Flight>((path) => {\n  apply(path, flightSchema);\n  required(path.id);\n});<\/code><\/pre>\n
      Another case where schemas refer to other schemas is conditional validation rules. Below, we will discuss this.<\/p>\n
      Controlling Form Behavior <\/span><\/h3>\n
      Schemas not only define validation rules but also further behavior. For instance, the schema can also specify under which circumstances the formField<\/code> directive should disable a field:<\/p>\n
      \/\/ src\/app\/domains\/ticketing\/data\/flight-schema.ts\n\nimport { disabled } from '@angular\/forms\/signals';\n\n[...]\n\ndisabled(path.delay, (ctx) => !ctx.valueOf(path.delayed));\n\n[...]<\/code><\/pre>\n
      Instead of true<\/code>, you can also return a reason for the disabling:<\/p>\n
      \/\/ src\/app\/domains\/ticketing\/data\/flight-schema.ts\n\ndisabled(path.delay, (ctx) =>\n  !ctx.valueOf(path.delayed) ? "not delayed" : false,\n);<\/code><\/pre>\n
      All the reasons why a field is currently disabled are found in its disabledReasons<\/code> Signal:<\/p>\n
      <!-- src\/app\/domains\/ticketing\/feature-booking\/flight-edit\/flight-form\/flight-form.html -->\n\n@for (reason of flightForm.delay().disabledReasons(); track $index) {\n<p>Disabled because {{ reason.message }}<\/p>\n}<\/code><\/pre>\n
      The functions hidden<\/code> and readonly<\/code> can be used to hide or make fields read-only in the same way. However, they alway return boolean values and don't support reasons. <\/p>\n
      While Signal Forms automatically disables writing to bound fields, e.g., input elements, marked as read-only, hiding fields is left to the application. This is because usually, hiding a field also requires hiding its label and perhaps other UI elements. Hence, hidden is only a hint your template can use:<\/p>\n
      @if (!flightForm.delay().hidden()) {\n  <div class="form-group">\n    <label for="flight-delay">Delay (min)<\/label>\n    <input\n      class="form-control"\n      [formField]="flightForm.delay"\n      type="number"\n      id="flight-delay"\n    \/>\n  <\/div>\n}<\/code><\/pre>\n
      Debouncing in Signal Forms Explained <\/span><\/h3>\n
      Especially in reactive UIs with search inputs, debouncing is essential. Instead of firing an HTTP request on every keystroke, we wait until the user has stopped typing for a few milliseconds. In our example, this behavior appears in the flight search form:<\/p>\n
      \"Reactive<\/p>\n
      The form's behavior for debouncing is specified in its schema. For this, the debounce<\/code> function can be used:<\/p>\n
      \/\/ ...\/feature-booking\/reactive-flight-search\/reactive-flight-search.ts\n\n[...]\n\nimport { debounce, form, minLength, required } from "@angular\/forms\/signals";\n\n[...]\n\nprotected readonly filterForm = form(this.filter, (schema) => {\n  debounce(schema, 300);\n\n  required(schema.from);\n  minLength(schema.from, 3);\n});<\/code><\/pre>\n
      In most cases, just calling debounce<\/code> with the debounce time in milliseconds is exactly what you need. However, if you want to control the debounce time using code, you can also pass in a respective debouncer function:<\/p>\n
      filterForm = form(this.filter, (schema) => {\n  debounce(schema, (ctx, _abortSignal) => {\n    return new Promise((resolve) => {\n      setTimeout(resolve, 300);\n    });\n  });\n\n  required(schema.from);\n  minLength(schema.from, 3);\n});<\/code><\/pre>\n
      Now, the returned Promise controls the debouncing. When it resolves, Angular continues processing the changes.<\/p>\n
      Validating Against Zod and Standard Schema <\/span><\/h3>\n
      Often, there is already something, such as a Zod schema, that describes rules for valid objects. Perhaps you already have them for server-side code or you generate it from a JSON Schema or an Open API document. Fortunately, you can directly validate against such schemas:<\/p>\n
      \/\/ src\/app\/domains\/ticketing\/data\/flight-schema.ts\n\nimport { validateStandardSchema, schema } from "@angular\/forms\/signals";\nimport { FlightZodSchema } from ".\/flight-zod-schema";\n\n[...]\n\nexport const flightSchema = schema<Flight>((path) => {\n  validateStandardSchema(path, FlightZodSchema);\n  \/\/ ... other validation rules\n});<\/code><\/pre>\n
      This not only works with Zod but also with all other schema libraries that follow the Standard Schema definition.<\/p>\n
      Combined with the submit<\/code> function discussed above, this is a quick and effective way to establish a client-side validation.<\/p>\n
      Field Validation <\/span><\/h2>\n
      Validation is a crucial aspect of form handling. Signal Forms provide a comprehensive validation system that goes far beyond simple required fields. You can create custom validators, implement conditional validation rules, validate multiple fields together, and even perform asynchronous validation via HTTP calls. This section explores the various validation strategies available in Signal Forms.<\/p>\n
      Implementing Custom Validators for Signal Forms <\/span><\/h3>\n
      Custom validators allow you to implement validation logic that goes beyond the built-in validators. They can check against business rules and compare values. To set them up, the validate<\/code> function is used. It accepts the path to be validated and a lambda expression that performs the validation:<\/p>\n
      import { validate } from "@angular\/forms\/signals";\n\n[...]\n\nprotected readonly flightForm = form(this.flight, (path) => {\n  required(path.from);\n  required(path.to);\n  required(path.date);\n  minLength(path.from, 3);\n\n  const allowed = ['Graz', 'Hamburg', 'Z\u00fcrich'];\n  validate(path.from, (ctx) => {\n    const value = ctx.value();\n    if (allowed.includes(value)) {\n      return null;\n    }\n\n    return {\n      kind: 'city',\n      value,\n      allowed,\n    };\n  });\n});<\/code><\/pre>\n
      This example defines a custom rule that checks the field from<\/code> against a list of allowed airports. In case of an error, this validator returns a ValidationError<\/code> that identifies the validation error with a string kind<\/code>. The validator can provide more detailed error information using additional properties it can freely specify. If a validator detects multiple errors, it can also return an array of ValidationError<\/code> objects. If there are no errors, it returns the value null<\/code> \u2013 true to the motto: no complaints are praise enough.<\/p>\n
      Refactoring Validators into Functions <\/span><\/h3>\n
      To improve clarity and reuse, it is advisable to refactor custom validators to separate functions. They must at least accept the property to be validated. The type SchemaPathTree<T><\/code> is used for this purpose. A SchemaPathTree<string><\/code>, for example, refers to a property of type string<\/code>:<\/p>\n
      \/\/ src\/app\/domains\/ticketing\/data\/flight-validators.ts\n\nimport { SchemaPathTree, validate } from "@angular\/forms\/signals";\n\nexport function validateCity(path: SchemaPathTree<string>, allowed: string[]) {\n  validate(path, (ctx) => {\n    const value = ctx.value();\n    if (allowed.includes(value)) {\n      return null;\n    }\n\n    return {\n      kind: "city",\n      value,\n      allowed,\n    };\n  });\n}<\/code><\/pre>\n
      The validator shown here accepts the airports passed to the allowed<\/code> parameter. To use the validator, the application calls it in the schema:<\/p>\n
      \/\/ src\/app\/domains\/ticketing\/data\/flight-schema.ts\n\nimport { validateCity } from ".\/flight-validators";\n\n[...]\n\nexport const flightSchema = schema<Flight>((path) => {\n  [...]\n  validateCity(path.from, ["Graz", "Hamburg", "Z\u00fcrich"]);\n});<\/code><\/pre>\n
      Showing Validation Errors <\/span><\/h3>\n
      So far, we've only returned the errors<\/code> object to indicate validation errors. However, the validators provided by Angular also give us the option to specify an error message for the user:<\/p>\n
      required(path.from, { message: "Please enter a value!" });<\/code><\/pre>\n
      The validator places this error message in the message<\/code> property of the respective ValidationError<\/code> object. This means the application only needs to output all message<\/code> properties it finds in the errors<\/code> array. In our example, the ValidationErrorsPane<\/code> component handles this task. If a validation error does not have a message<\/code> property, a standard error message determined by the helper function toMessage<\/code> is used:<\/p>\n
      \/\/ src\/app\/domains\/shared\/ui-forms\/validation-errors\/validation-errors-pane.ts\n\nimport { Component, computed, input } from "@angular\/core";\nimport { MinValidationError, ValidationError } from "@angular\/forms\/signals";\n\n@Component({\n  selector: "app-validation-errors-pane",\n  imports: [],\n  templateUrl: ".\/validation-errors-pane.html",\n})\nexport class ValidationErrorsPane {\n  readonly errors = input.required<ValidationError.WithField[]>();\n  readonly showFieldNames = input(false);\n\n  protected readonly errorMessages = computed(() =>\n    toErrorMessages(this.errors(), this.showFieldNames()),\n  );\n}\n\nfunction toErrorMessages(\n  errors: ValidationError.WithField[],\n  showFieldNames: boolean,\n): string[] {\n  return errors.map((error) => {\n    const prefix = showFieldNames ? toFieldName(error) + ": " : "";\n\n    const message = error.message ?? toMessage(error);\n    return prefix + message;\n  });\n}\n\nfunction toFieldName(error: ValidationError.WithField) {\n  return error.fieldTree().name().split(".").at(-1);\n}\n\nfunction toMessage(error: ValidationError): string {\n  switch (error.kind) {\n    case "required":\n      return "Enter a value!";\n    case "roundtrip":\n    case "roundtrip_tree":\n      return "Roundtrips are not supported!";\n    case "min":\n      return Minimum amount: ${(error as MinValidationError).min}<\/code>;\n    default:\n      return error.kind ?? "Validation Error";\n  }\n}<\/code><\/pre>\n
      The template displays the error messages obtained in this way:<\/p>\n
      <!-- src\/app\/domains\/shared\/ui-forms\/validation-errors\/validation-errors-pane.html -->\n\n@if (errorMessages().length > 0) {\n<div class="validation-errors">\n  @for(message of errorMessages(); track message) {\n  <div>{{ message }}<\/div>\n  }\n<\/div>\n}<\/code><\/pre>\n
      The consumer must now delegate to the ValidationErrorsPane<\/code> component for each field and pass the errors<\/code> array:<\/p>\n
      <!-- ...\/ticketing\/feature-booking\/flight-edit\/flight-form\/flight-form.html -->\n\n<div class="form-group">\n  <label for="flight-from">From<\/label>\n  <input [formField]="flightForm.from" id="flight-from" \/>\n  <app-validation-errors-pane [errors]="flightForm.from().errors()" \/>\n<\/div><\/code><\/pre>\n
      Conditional Validation <\/span><\/h3>\n
      Some validation rules only apply under specific circumstances. In the application shown, delay<\/code> needs to be validated only when delayed<\/code> is true<\/code>. This simple case is representative of more complex cases in which the value of one field affects the validation of other fields.<\/p>\n
      Such situations can be handled with the applyWhenValue<\/code> function. It accepts the path to be validated, a predicate \u2014 typically a lambda expression \u2014 and a schema. If the predicate returns true<\/code>, applyWhenValue<\/code> applies the schema:<\/p>\n
      \/\/ src\/app\/domains\/ticketing\/data\/flight-schema.ts\n\nimport { applyWhenValue, required, min, schema } from "@angular\/forms\/signals";\n\n[...]\n\nexport const flightSchema = schema<Flight>((path) => {\n  \/\/ ...\n  applyWhenValue(path, (flight) => flight.delayed, delayedFlight);\n});\n\nexport const delayedFlight = schema<Flight>((path) => {\n  required(path.delay);\n  min(path.delay, 15);\n});<\/code><\/pre>\n
      The schema contains the conditional validation rules. There are a few alternatives to applyWhenValue<\/code>. One of them is applyWhen<\/code>, whose predicate receives the current context, which provides access to the entire field state:<\/p>\n
      applyWhen(path, (ctx) => ctx.valueOf(path.delayed), delayedFlight);<\/code><\/pre>\n
      Besides valueOf<\/code>, the context also provides a function stateOf that returns the entire field state of a given path. This is useful if the predicate needs to check properties such as dirty<\/code> or touched<\/code>. <\/p>\n
      Another option for conditional validations is the when<\/code> property provided by the required<\/code> validator:<\/p>\n
      required(path.delay, {\n  when: (ctx) => ctx.valueOf(path.delayed),\n});<\/code><\/pre>\n
      Cross-Field Validation in Signal Forms <\/span><\/h3>\n
      Sometimes we need to respect multiple fields to perform a validation. One option for achieving this is a validator provided for a common parent. For example, if a validator needs to ensure that from<\/code> and to<\/code> have different values, the application can implement it as a validator for the entire flight<\/code>:<\/p>\n
      \/\/ src\/app\/domains\/ticketing\/data\/flight-validators.ts\n\nimport { SchemaPathTree, validate } from "@angular\/forms\/signals";\nimport { Flight } from ".\/flight";\n\nexport function validateRoundTrip(schema: SchemaPathTree<Flight>) {\n  validate(schema, (ctx) => {\n    const from = ctx.fieldTree.from().value();\n    const to = ctx.fieldTree.to().value();\n\n    \/\/ Alternative:\n    \/\/ const from = ctx.valueOf(schema.from);\n    \/\/ const to = ctx.valueOf(schema.to);\n\n    if (from === to) {\n      return {\n        kind: "roundtrip",\n        from,\n        to,\n      };\n    }\n    return null;\n  });\n}<\/code><\/pre>\n
      As usual, this validator must be included in the schema:<\/p>\n
      \/\/ src\/app\/domains\/ticketing\/data\/flight-schema.ts\n\nimport { validateRoundTrip } from ".\/flight-validators";\n\nexport const flightSchema = schema<Flight>((path) => {\n  \/\/ ...\n  validateRoundTrip(path);\n});<\/code><\/pre>\n
      Validators always return error messages for the validated level. In this case, this is the flight<\/code> itself, not from<\/code> or to<\/code>. Therefore, the application also uses the flight<\/code>'s errors<\/code> array:<\/p>\n
      <!-- src\/app\/domains\/ticketing\/feature-booking\/flight-edit\/flight-edit.html -->\n\n<app-validation-errors-pane [errors]="flightForm().errors()" \/>\n<form>[\u2026]<\/form><\/code><\/pre>\n
      In the screenshot shown initially, this is the first error message the component displays above the form. Validation errors from lower levels do not appear in errors<\/code>. To retrieve these, the application can access the errors<\/code> array on the respective level or a parent's errorSummary<\/code>:<\/p>\n
      <app-validation-errors-pane [errors]="flightForm().errorSummary()" \/>\n<form>[\u2026]<\/form><\/code><\/pre>\n
      Since this will reveal error messages for different levels and fields, it makes sense to output the name of the affected field for each error. This information can also be found in the individual ValidationError<\/code> objects. The ValidationErrorsPane<\/code> component in my examples<\/a> (see branch signal-forms-example<\/code>), which is somewhat more comprehensive than the variant discussed here, takes advantage of this option.<\/p>\n
      Accessing Sibling Fields <\/span><\/h3>\n
      An alternative implementation of the roundtrip validator in the previous section is to define a validator for from<\/code> that also has access to its sibling field to<\/code>. This is done using the valueOf<\/code> function provided by the validation context:<\/p>\n
      export function validateRoundTrip2(schema: SchemaPathTree<Flight>) {\n  \/\/ Now, we are validating the 'from' field only\n  validate(schema.from, (ctx) => {\n    const from = ctx.value();\n    const to = ctx.valueOf(schema.to);\n\n    if (from === to) {\n      return {\n        kind: 'roundtrip',\n        from,\n        to,\n      };\n    }\n    return null;\n  });\n}<\/code><\/pre>\n
      In this case, the error message appears in the from<\/code> field's errors<\/code> array:<\/p>\n
      <app-validation-errors-pane [errors]="flightForm.from().errors()" \/><\/code><\/pre>\n
      Tree Validators <\/span><\/h3>\n
      Tree validators are special multi-field validators that can define error messages for all levels of a field tree. To do so, they store the affected field in the ValidationError<\/code> object:<\/p>\n
      \/\/ src\/app\/domains\/ticketing\/data\/flight-validators.ts\n\nimport { SchemaPathTree, validateTree } from "@angular\/forms\/signals";\nimport { Flight } from ".\/flight";\n\nexport function validateRoundTripTree(schema: SchemaPathTree<Flight>) {\n  validateTree(schema, (ctx) => {\n    const from = ctx.fieldTree.from().value();\n    const to = ctx.fieldTree.to().value();\n\n    if (from === to) {\n      return {\n        kind: "roundtrip_tree",\n        field: ctx.fieldTree.from,\n        from,\n        to,\n      };\n    }\n    return null;\n  });\n}<\/code><\/pre>\n
      After registering in the schema, the error message now appears at field level:<\/p>\n
      \/\/ src\/app\/domains\/ticketing\/data\/flight-schema.ts\n\nimport { validateRoundTripTree } from ".\/flight-validators";\n\nexport const flightSchema = schema<Flight>((path) => {\n  \/\/ ...\n  validateRoundTripTree(path);\n});<\/code><\/pre>\n
      In the initial screenshot shown above, this error message is the second one from the top.<\/p>\n
      Since each validator can return multiple error messages in the form of an array, a tree validator can also return error messages for different fields. This makes it ideal for complex rules. Simple rules, however, can also be implemented as conventional validators that have access to neighboring fields:<\/p>\n
      validate(path.to, (ctx) => {\n  if (ctx.value() === ctx.valueOf(path.from)) {\n    return { kind: "roundtrip" };\n  }\n  return null;\n});<\/code><\/pre>\n
      Asynchronous Validators for Signal Forms <\/span><\/h3>\n
      Asynchronous validators do not deliver validation results instantly; they determine them asynchronously. Typically, this is done via an HTTP call. The validateAsync<\/code> function provided by Signal Forms enables this approach. It defines four mappings:<\/p>\n
        \n
      • params<\/code> maps the form state to parameters<\/li>\n
      • factory<\/code> creates a resource with these parameters<\/li>\n
      • onSuccess<\/code> maps the result determined by the resource to a ValidationError<\/code> or a ValidationError<\/code> array<\/li>\n
      • onError<\/code> maps a possible error returned by the resource to a ValidationError<\/code> or a ValidationError<\/code> array<\/li>\n<\/ul>\n
        The following listing demonstrates this using an rxResource<\/code> that uses the rxValidateAirport<\/code> function to simulate an HTTP call for validating an airport:<\/p>\n
        \/\/ src\/app\/domains\/ticketing\/data\/flight-validators.ts\n\nimport { rxResource } from "@angular\/core\/rxjs-interop";\nimport { SchemaPathTree, validateAsync, metadata } from "@angular\/forms\/signals";\nimport { delay, map, Observable, of } from "rxjs";\n\nexport function validateCityAsync(schema: SchemaPathTree<string>) {\n  validateAsync(schema, {\n    params: (ctx) => ({\n      value: ctx.value(),\n    }),\n    factory: (params) => {\n      return rxResource({\n        params,\n        stream: (p) => {\n          return rxValidateAirport(p.params.value);\n        },\n      });\n    },\n    onSuccess: (result: boolean, _ctx) => {\n      if (!result) {\n        return {\n          kind: "airport_not_found_http",\n        };\n      }\n      return null;\n    },\n    onError: (error, _ctx) => {\n      console.error("api error validating city", error);\n      return {\n        kind: "api-failed",\n      };\n    },\n  });\n}\n\n\/\/ Simulates a server-side validation\nfunction rxValidateAirport(airport: string): Observable<boolean> {\n  const allowed = ["Graz", "Hamburg", "Z\u00fcrich"];\n  return of(null).pipe(\n    delay(2000),\n    map(() => allowed.includes(airport)),\n  );\n}<\/code><\/pre>\n
        As usual, this validator must also be added to the schema:<\/p>\n
        \/\/ src\/app\/domains\/ticketing\/data\/flight-schema.ts\n\nimport { validateCityAsync } from ".\/flight-validators";\n\n[...]\n\nexport const flightSchema = schema<Flight>((path) => {\n  [...]\n  validateCityAsync(path.from);\n});<\/code><\/pre>\n
        As long as at least one synchronous validator fails, Angular doesn't execute asynchronous validators. This prevents unnecessary server calls. While Signal Forms waits for the result of an asynchronous validator, the pending<\/code> property of the affected field is true<\/code>:<\/p>\n
        <!-- ...\/ticketing\/feature-booking\/flight-edit\/flight-form\/flight-form.html -->\n\n@if (flightForm.from().pending()) {\n<div>Waiting for Async Validation Result...<\/div>\n}<\/code><\/pre>\n
        HTTP Validators <\/span><\/h3>\n
        Most asynchronous validators initiate HTTP requests. Therefore, validateHttp<\/code> provides a simplified version that directly returns a request for an HttpResource<\/code>:<\/p>\n
        \/\/ src\/app\/domains\/ticketing\/data\/flight-validators.ts\n\nimport { SchemaPathTree, validateHttp, metadata } from "@angular\/forms\/signals";\nimport { Flight } from ".\/flight";\nimport { CITY } from "..\/..\/shared\/util-common\/properties";\n\nexport function validateCityHttp(schema: SchemaPathTree<string>) {\n  metadata(schema, CITY, () => true);\n\n  validateHttp(schema, {\n    request: (ctx) => ({\n      url: "https:\/\/demo.angulararchitects.io\/api\/flight",\n      params: {\n        from: ctx.value(),\n      },\n    }),\n    onSuccess: (result: Flight[], _ctx) => {\n      if (result.length === 0) {\n        return {\n          kind: "airport_not_found_http",\n        };\n      }\n      return null;\n    },\n    onError: (error, _ctx) => {\n      console.error("api error validating city", error);\n      return {\n        kind: "api-failed",\n      };\n    },\n  });\n}<\/code><\/pre>\n
        As usual, onSuccess<\/code> maps the result of the resource to ValidationError<\/code> objects and onError<\/code> projects errors provided by the resource to this type. Here, too, you should remember to anchor the validator in the schema:<\/p>\n
        \/\/ src\/app\/domains\/ticketing\/data\/flight-schema.ts\n\nimport { validateCityHttp } from ".\/flight-validators";\n\n[...]\n\nexport const flightSchema = schema<Flight>((path) => {\n  [...]\n  validateCityHttp(path.to);\n});<\/code><\/pre>\n
        Nested Forms and Form Arrays <\/span><\/h2>\n
        Real-world applications often require forms that go beyond simple flat structures. Signal Forms support complex, nested data models with objects and arrays. This section demonstrates how to work with form groups (nested objects) and form arrays (repeating groups), and how to break down large forms into smaller, more manageable sub-components.<\/p>\n
        Form Groups <\/span><\/h3>\n
        So far, we've only bound a flat flight<\/code> object to a form. However, Signal Forms also support more complex structures. To illustrate this, let's write validation rules for the aircraft<\/code> object connected to a flight:<\/p>\n
        \/\/ src\/app\/domains\/ticketing\/data\/aircraft-schema.ts\n\nimport { required, schema } from "@angular\/forms\/signals";\nimport { Aircraft } from ".\/aircraft";\n\nexport const aircraftSchema = schema<Aircraft>((path) => {\n  required(path.registration);\n  required(path.type);\n});<\/code><\/pre>\n
        The flight schema uses the aircraft schema:<\/p>\n
        \/\/ src\/app\/domains\/ticketing\/data\/flight-schema.ts\n\nimport { apply } from "@angular\/forms\/signals";\nimport { aircraftSchema } from ".\/aircraft-schema";\n\n[...]\n\nexport const flightSchema = schema<Flight>((path) => {\n  [...]\n  apply(path.aircraft, aircraftSchema);\n});<\/code><\/pre>\n
        The aircraft can be directly accessed via the flight. To avoid long chains like flightForm.aircraft.registration().errors()<\/code>, I create an alias for each additional level using let<\/code>:<\/p>\n
        <!-- \n ...\/ticketing\/feature-booking\/flight-edit\/aircraft-form\/aircraft-form.html \n-->\n\n@let aircraftForm = aircraft();\n\n<fieldset>\n  <legend>Aircraft<\/legend>\n\n  <div class="form-group">\n    <label for="type">Type:<\/label>\n    <input id="type" class="form-control" [formField]="aircraftForm.type" \/>\n    <app-validation-errors-pane [errors]="aircraftForm.type().errors()" \/>\n  <\/div>\n  <div class="form-group">\n    <label for="registration">Registration:<\/label>\n    <input\n      id="registration"\n      class="form-control"\n      [formField]="aircraftForm.registration"\n    \/>\n    <app-validation-errors-pane\n      [errors]="aircraftForm.registration().errors()"\n    \/>\n  <\/div>\n<\/fieldset><\/code><\/pre>\n
        Form Arrays  <\/span><\/h3>\n
        The repeating group with the prices<\/code> is designed similarly to the aircraft form. First, you need to set up a schema:<\/p>\n
        \/\/ src\/app\/domains\/ticketing\/data\/price-schema.ts\n\nimport { min, required, schema } from "@angular\/forms\/signals";\nimport { Price } from ".\/price";\n\nexport const initPrice: Price = {\n  flightClass: "",\n  amount: 0,\n};\n\nexport const priceSchema = schema<Price>((path) => {\n  required(path.flightClass);\n  required(path.amount);\n  min(path.amount, 0);\n});<\/code><\/pre>\n
        Unlike before, the flight schema must set up the pricing scheme for each individual price. Therefore, the applyEach<\/code> function is used here instead of apply<\/code>:<\/p>\n
        \/\/ src\/app\/domains\/ticketing\/data\/flight-schema.ts\n\nimport { applyEach, schema } from "@angular\/forms\/signals";\nimport { priceSchema } from ".\/price-schema";\n\nexport const flightSchema = schema<Flight>((path) => {\n  \/\/ ...\n  applyEach(path.prices, priceSchema);\n});<\/code><\/pre>\n
        In the template, the prices must now be iterated, and corresponding fields must be presented for each price:<\/p>\n
        <!-- ...\/ticketing\/feature-booking\/flight-edit\/prices-form\/prices-form.html -->\n\n@let priceForms = prices();\n\n<fieldset>\n  <legend>Prices<\/legend>\n  <app-validation-errors-pane [errors]="priceForms().errors()" \/>\n  <table class="datagrid">\n    <tr>\n      <th>Flight Class<\/th>\n      <th>Amount<\/th>\n      <th><\/th>\n    <\/tr>\n    @for (price of priceForms; track $index) {\n    <tr>\n      <td>\n        <input [formField]="price.flightClass" class="medium" \/>\n      <\/td>\n      <td>\n        <input [formField]="price.amount" type="number" class="small" \/>\n      <\/td>\n      <td class="error-col">\n        <app-validation-errors-pane\n          [errors]="price().errorSummary()"\n          [showFieldNames]="true"\n        \/>\n      <\/td>\n    <\/tr>\n    }\n  <\/table>\n  <button (click)="addPrice()" type="button" class="btn btn-default ml3">\n    Add\n  <\/button>\n<\/fieldset><\/code><\/pre>\n
        The Add<\/code> button adds a new price to the array. This causes Angular to present fields for it as well:<\/p>\n
        addPrice(): void {\n  const pricesForms = this.prices();\n  pricesForms().value.update((prices) => [...prices, { ...initPrice }]);\n}<\/code><\/pre>\n
        Validating Form Arrays <\/span><\/h3>\n
        Validation rules can be defined for all nodes in the object graph shown. Arrays like our prices are no exception. The following listing demonstrates this using a validator that iterates through all prices and checks for duplicates:<\/p>\n
        \/\/ src\/app\/domains\/ticketing\/data\/flight-validators.ts\n\nimport { SchemaPath, validate } from "@angular\/forms\/signals";\nimport { Price } from ".\/price";\n\nexport function validateDuplicatePrices(prices: SchemaPath<Price[]>) {\n  validate(prices, (ctx) => {\n    const prices = ctx.value();\n    const flightClasses = new Set<string>();\n\n    for (const price of prices) {\n      if (flightClasses.has(price.flightClass)) {\n        return {\n          kind: "duplicateFlightClass",\n          message: "There can only be one price per flight class",\n          flightClass: price.flightClass,\n        };\n      }\n      flightClasses.add(price.flightClass);\n    }\n\n    return null;\n  });\n}<\/code><\/pre>\n
        As always, you have to remember to include the validation rule:<\/p>\n
        \/\/ src\/app\/domains\/ticketing\/data\/flight-schema.ts\n\nimport { validateDuplicatePrices } from ".\/flight-validators";\n\n[...]\n\nexport const flightSchema = schema<Flight>((path) => {\n  [...]\n  validateDuplicatePrices(path.prices);\n});<\/code><\/pre>\n
        Nested Forms (Subforms) <\/span><\/h3>\n
        The code of large forms can quickly become unwieldy. Therefore, it's a good idea to break them down into multiple components. Let's imagine that our flight form is composed of three types: the flight itself, an aircraft, and prices: <\/p>\n
        \"Flights<\/p>\n
        For these parts, we could define subforms. The main FlightEdit<\/code> component then imports these components: <\/p>\n
        \/\/ src\/app\/domains\/ticketing\/feature-booking\/flight-edit\/flight-edit.ts\n[...]\n\nimport { AircraftForm } from '.\/aircraft-form\/aircraft-form';\nimport { FlightForm } from '.\/flight-form\/flight-form';\nimport { PricesForm } from '.\/prices-form\/prices-form';\n\n@Component({\n  selector: 'app-flight-edit',\n  imports: [\n    AircraftForm,\n    PricesForm,\n    FlightForm,\n    ValidationErrorsPane,\n    RouterLink,\n  ],\n  templateUrl: '.\/flight-edit.html',\n  changeDetection: ChangeDetectionStrategy.OnPush,\n})\nexport class FlightEdit {\n  [...]\n}<\/code><\/pre>\n
        These components each receive a portion of the entire Signal Form via data binding:<\/p>\n
        <!-- src\/app\/domains\/ticketing\/feature-booking\/flight-edit\/flight-edit.html -->\n\n@if (flight().id !== 0) {\n<app-validation-errors-pane [errors]="flightForm().errors()" \/>\n<form class="flight-form" novalidate>\n  <app-flight [flight]="flightForm"><\/app-flight>\n  <app-prices [prices]="flightForm.prices"><\/app-prices>\n  <app-aircraft [aircraft]="flightForm.aircraft"><\/app-aircraft>\n\n  <div class="mt-40">\n    <button type="button" (click)="save()">Save<\/button>\n  <\/div>\n<\/form>\n}<\/code><\/pre>\n
        Angular represents these individual parts as FieldTree<T><\/code>. Inputs must be set up for this:<\/p>\n
        \/\/ ...\/ticketing\/feature-booking\/flight-edit\/aircraft-form\/aircraft-form.ts\n\nimport { Component, input } from "@angular\/core";\nimport { FieldTree, FormField } from "@angular\/forms\/signals";\n\nimport { ValidationErrorsPane } \n  from "..\/..\/..\/..\/shared\/ui-forms\/validation-errors\/validation-errors-pane";\nimport { Aircraft } from "..\/..\/..\/data\/aircraft";\n\n@Component({\n  selector: "app-aircraft",\n  imports: [FormField, ValidationErrorsPane],\n  templateUrl: ".\/aircraft-form.html",\n})\nexport class AircraftForm {\n  aircraft = input.required<FieldTree<Aircraft>>();\n}<\/code><\/pre>\n
        For arrays like the price array in our example, the same procedure applies:<\/p>\n
        \/\/ ...\/ticketing\/feature-booking\/flight-edit\/prices-form\/prices-form.ts\n\nimport { Component, input } from "@angular\/core";\nimport { FieldTree, FormField } from "@angular\/forms\/signals";\n\nimport { ValidationErrorsPane } \n  from "..\/..\/..\/..\/shared\/ui-forms\/validation-errors\/validation-errors-pane";\nimport { Price } from "..\/..\/..\/data\/price";\nimport { initPrice } from "..\/..\/..\/data\/price-schema";\n\n@Component({\n  selector: "app-prices",\n  imports: [FormField, ValidationErrorsPane],\n  templateUrl: ".\/prices-form.html",\n})\nexport class PricesForm {\n  readonly prices = input.required<FieldTree<Price[]>>();\n\n  addPrice(): void {\n    const pricesForms = this.prices();\n    pricesForms().value.update((prices) => [...prices, { ...initPrice }]);\n  }\n}<\/code><\/pre>\n
        How Form Metadata Works? <\/span><\/h2>\n
        Instead of telling users after they entered something invalid, Signal Forms can provide metadata that tells them upfront what they are expected to provide:<\/p>\n
        \"Field<\/p>\n
        For displaying the metadata, our example uses a component app-field-meta-data-pane<\/code> that is imported into the flight form:<\/p>\n
        [...]\n\nimport { FieldMetaDataPane } from '..\/..\/..\/shared\/ui-forms\/field-meta-data-pane\/field-meta-data-pane';\n\n[...]\n\n@Component({\n  selector: 'app-flight-edit',\n  imports: [[...], FieldMetaDataPane],\n  [...]\n})\nexport class FlightEdit {\n  [...]\n}<\/code><\/pre>\n
        In the template, it displays the metadata next to the respective field:<\/p>\n
        <!-- ...\/ticketing\/feature-booking\/flight-edit\/flight-form\/flight-form.html -->\n\n<div class="form-group">\n  <label for="flight-from">\n    From\n    <app-field-meta-data-pane [field]="flightForm.from" \/>\n  <\/label>\n  <input class="form-control" [formField]="flightForm.from" id="flight-from" \/>\n  [...]\n<\/div><\/code><\/pre>\n
        How to Read Form Metadata? <\/span><\/h3>\n
        To read the metadata, call the metadata<\/code> method with a key, e.g., REQUIRED<\/code> or MIN_LENGTH<\/code>. As we will see in a second, you can also define your own keys, such as CITY<\/code> or CITY2<\/code>. What you get back is either the metadata property itself or a Signal containing the property (more about this below), which you can display to the user:<\/p>\n
        \/\/ src\/app\/domains\/shared\/ui-forms\/field-meta-data-pane\/field-meta-data-pane.ts\n\nimport { Component, computed, input } from "@angular\/core";\nimport {\n  FieldTree,\n  REQUIRED,\n  MIN_LENGTH,\n  MAX_LENGTH,\n} from "@angular\/forms\/signals";\n\nimport { CITY, CITY2 } from "..\/..\/util-common\/properties";\n\n@Component({\n  selector: "app-field-meta-data-pane",\n  imports: [],\n  templateUrl: ".\/field-meta-data-pane.html",\n})\nexport class FieldMetaDataPane {\n  readonly field = input.required<FieldTree<unknown>>();\n\n  protected readonly fieldState = computed(() => this.field()());\n\n  protected readonly isRequired = computed(\n    () => this.fieldState().metadata(REQUIRED)?.() ?? false,\n  );\n  protected readonly minLength = computed(\n    () => this.fieldState().metadata(MIN_LENGTH)?.() ?? 0,\n  );\n  protected readonly maxLength = computed(\n    () => this.fieldState().metadata(MAX_LENGTH)?.() ?? 30,\n  );\n  protected readonly length = computed(\n    () => (${this.minLength()}..${this.maxLength()})<\/code>,\n  );\n\n  protected readonly city = computed(() => this.fieldState().metadata(CITY));\n  protected readonly city2 = computed(() => this.fieldState().metadata(CITY2));\n}<\/code><\/pre>\n
        Here is the template for this component:<\/p>\n
        <!-- ...\/shared\/ui-forms\/field-meta-data-pane\/field-meta-data-pane.html -->\n\n@if (isRequired()) {\n<span class="info">*<\/span>\n}\n<span class="info info-small">{{ length() }}<\/span>\n@if (city()) {\n<span class="info info-small">City<\/span>\n} @if (city2()) {\n<span class="info info-small">City<\/span>\n}<\/code><\/pre>\n
        How to Define Custom Form Metadata? <\/span><\/h3>\n
        You create your own simple property with createMetadataKey<\/code>:<\/p>\n
        \/\/ src\/app\/domains\/shared\/util-common\/properties.ts\n\nimport { createMetadataKey, MetadataReducer } from "@angular\/forms\/signals";\n\n\/\/\n\/\/  Property\n\/\/\nexport const CITY = createMetadataKey<boolean>();\n\n\/\/\n\/\/  AggregateProperty\n\/\/\nexport const CITY2 = createMetadataKey(MetadataReducer.or());<\/code><\/pre>\n
        Now it gets a bit spicy: Let's imagine two validators define different values for the same property. The first one defines CITY<\/code> as true<\/code>, the second one as false<\/code>. By default, the last defined value wins. However, if you define a reducer like CITY2<\/code>, you can control how multiple values are combined.<\/p>\n
        The reducer MetadataReducer.or()<\/code> combines them via a logical OR (value1 || value2 || value3<\/code>). Besides this, there is, for instance, MetadataReducer.and()<\/code>, MetadataReducer.min()<\/code>, MetadataReducer.max()<\/code>, and MetadataReducer.list()<\/code>. The latter puts all values into an array.<\/p>\n
        For special cases, you can also implement your own reducer by implementing the MetadataReducer<T><\/code> interface. To illustrate this, here is a custom reducer that also combines boolean values via a logical OR:<\/p>\n
        const myOr: MetadataReducer<boolean, boolean> = {\n  reduce(acc, item) {\n    return acc || item;\n  },\n  getInitial() {\n    return false;\n  }\n};\n\nexport const CITY3 = createMetadataKey(myOr);<\/code><\/pre>\n
        To define a value for a metadata key, we use the metadata<\/code> function. You can call it directly in the schema, but most likely, you'll call it inside a custom validator where you already define what you expect from the user:<\/p>\n
        \/\/ src\/app\/domains\/ticketing\/data\/flight-validators.ts\n\nexport function validateCityHttp(schema: SchemaPath<string>) {\n  metadata(schema, CITY, () => true);\n\n  validateHttp(schema, { ... });\n}<\/code><\/pre>\n
        Null and Undefined Values <\/span><\/h2>\n
        It might come as a surprise that Signal Forms do not allow undefined<\/code> values. The reason for this design decision is that undefined<\/code> semantically means that the field does not exist. When initialized with an undefined<\/code> value, Signal Forms's form<\/code> function has no way of knowing that this field is supposed to exist in the form.<\/p>\n
        To make this clearer, let\u2019s use a thought experiment where the delay<\/code> of our flights is optional:<\/p>\n
        export interface FlightDomainModel {\n  id: string;\n  from: string;\n  to: string;\n  date: string;\n  delayed: boolean;\n\n  \/\/ Optional delay \n  delay?: number\n}<\/code><\/pre>\n
        Let's further assume that the backend only expects a delay<\/code> value when delayed<\/code> is true<\/code>. In all other cases, the field is omitted and hence undefined<\/code>. If you now create a Signal Form for this model in a component without a delay<\/code>, Angular Signal forms cannot find the needed metadata for the delay<\/code> field. From it's perspective, this field does not exist.<\/p>\n
        However, from the form's perspective, the field always exists while sometimes it has no value. This shows that we have a different perspective from the domain perspective than from the form perspective. For this reason the Angular team recommends to distinguish between the two perspectives by defining two separate types:<\/p>\n
        export interface FlightFormModel {\n  id: string;\n  from: string;\n  to: string;\n  date: string;\n  delayed: boolean;\n  delay: number\n}<\/code><\/pre>\n
        Instead of undefined<\/code> you can use null<\/code> as it has the semantic of 'empty value'. However, it would be even better to go with a sound default value. In our example, we can simply set the default delay to 0<\/code>. To bridge between the domain model and the form model, we can use mapping functions when creating the Signal Form:<\/p>\n
        export function toFlightFormModel(model: FlightDomainModel): FlightFormModel {\n  return {\n    ...model,\n    delay: model.delay ?? 0,\n  };\n}<\/code><\/pre>\n
        For converting back we could use a similar function, given the backend does not accept a delay of 0<\/code> when delayed<\/code> is false<\/code>:<\/p>\n
        export function toFlightDomainModel(model: FlightFormModel): FlightDomainModel {\n  return {\n    ...model,\n    delay: model.delayed ? undefined : model.delay,\n  };\n}<\/code><\/pre>\n
        Furthermore, in our component we can use a linked signal to automatically convert the domain model to the form model within the reactive data flow:<\/p>\n
        protected readonly flightDomainModel = signal<FlightDomainModel>({\n  id: 0,\n  from: '',\n  to: '',\n  date: '',\n  delayed: false,\n});\n\nprotected readonly flightFormModel = linkedSignal(\n  () => toFlightFormModel(this.flightDomainModel())\n);\n\nprotected readonly flightForm = form(this.flightFormModel);<\/code><\/pre>\n
        When saving the form, we need to convert back to the domain model:<\/p>\n
        protected save(): void {\n  const formModel = this.flightForm().value();\n  const domainModel = toFlightDomainModel(formModel);\n  [...]\n}<\/code><\/pre>\n
        When the form model needs to be converted back immediately after typing, a delegated signal as described in chapter xyz can be used.<\/p>\n
        The same strategy is useful when dealing with fields that appear conditionally. From the form's perspective, these fields always exist, even if they are hidden in the UI. Hence, the correct way for modelling them is to always have them in the form model and to convert them accordingly when mapping to\/from the domain model.<\/p>\n
        Creating Custom Fields <\/span><\/h2>\n
        So far, we've only used the FormField<\/code> directive with standard HTML tags. The question now is how to make this directive work with our own widgets. For example, let's imagine a DelayStepper<\/code> component to change the flight delay in 15-minute increments. This should be able to be bound to a field with FormField<\/code>, just like all other fields:<\/p>\n
        <!-- ...\/ticketing\/feature-booking\/flight-edit\/flight-form\/flight-form.html -->\n\n<div class="form-group form-check">\n  <label for="delay">Delay<\/label>\n  <app-delay-stepper id="delay" [formField]="flightForm.delay" \/>\n  <app-validation-errors-pane [errors]="flightForm.delay().errors()" \/>\n<\/div><\/code><\/pre>\n
        In the past, such widgets had to be provided with a so-called Control Value Accessor. Unfortunately, this wasn't exactly straightforward. Signal Forms makes the whole process much simpler: The widget implements the FormValueControl<T><\/code> interface, which just enforces a ModelSignal<\/code> named value<\/code>. It also defines other optional properties, such as disabled<\/code> or errors<\/code>, which the widget can access as needed:<\/p>\n
        \/\/ src\/app\/domains\/shared\/ui-common\/delay-stepper\/delay-stepper.ts\n\nimport { Component, effect, input, model } from "@angular\/core";\nimport { FormValueControl, ValidationError } from "@angular\/forms\/signals";\n\n@Component({\n  selector: "app-delay-stepper",\n  imports: [],\n  templateUrl: ".\/delay-stepper.html",\n  styleUrl: ".\/delay-stepper.css",\n})\nexport class DelayStepper implements FormValueControl<number> {\n  readonly value = model(0);\n\n  readonly disabled = input(false);\n  readonly errors = input<readonly ValidationError.WithOptionalField[]>([]);\n\n  constructor() {\n    effect(() => {\n      console.log("DelayStepper, errors", this.errors());\n    });\n  }\n\n  protected inc(): void {\n    this.value.update((v) => v + 15);\n  }\n\n  protected dec(): void {\n    this.value.update((v) => Math.max(v - 15, 0));\n  }\n}<\/code><\/pre>\n
        The DelayStepper<\/code> component uses the disabled<\/code> property to indicate whether the field is disabled due to a schema rule. It receives all validation errors from Signal Forms via errors<\/code>. This property is displayed with an effect for the sake of demonstration. The disabled<\/code> property is used alongside the value<\/code> in the template:<\/p>\n
        <!-- src\/app\/domains\/shared\/ui-common\/delay-stepper\/delay-stepper.html -->\n\n@if(disabled()) {\n<div class="delay">No Delay!<\/div>\n} @else {\n<div class="delay">{{ value() }}<\/div>\n<div>\n  <a (click)="inc()">+15 Minutes<\/a> |\n  <a (click)="dec()">-15 Minutes<\/a>\n<\/div>\n}<\/code><\/pre>\n
        Note on Custom Checkboxes <\/span><\/h3>\n
        FormValueControl<\/code> can also be used for checkboxes, as it provides an optional checked<\/code> property. However, for this purpose, Signal Forms also provides a specialized FormCheckboxControl<\/code> interface. It defines a mandatory checked<\/code> property and an optional value<\/code>. <\/p>\n
        Conclusion <\/span><\/h2>\n
        Signal Forms show where Angular is heading: toward a form model that is fully reactive, strongly typed, and built around Signals. Instead of treating forms as a separate subsystem, they integrate form state, validation, and UI behavior into one coherent, composable API\u2014scaling from simple fields to nested object graphs and arrays.<\/p>\n
        What stands out is the breadth of validation options (custom, conditional, multi-field, tree-based, and async\/HTTP) and how naturally these rules can be organized via schemas and reusable validator functions. Combined with metadata, forms can not only detect errors but also communicate expectations early, leading to a smoother user experience.<\/p>\n
        Signal Forms are still experimental, but they are already worth exploring in real-world scenarios: start with a single feature form, extract reusable schemas, and incrementally add advanced validation where it delivers the most value. If you try them early and provide feedback, you can help shape a form API that many Angular apps will benefit from in the near future.<\/p>\n","protected":false},"excerpt":{"rendered":"
        This is post 2 of 3 in the series “Signal Forms” Dynamic Forms: Building a Form Generator with Signal Forms Angular Signal Forms – Everything You Need to Know Migrating to Angular Signal Forms: Interop with Reactive Forms The long-awaited Signal Forms bridge a crucial gap between Angular’s Signal-based reactivity and user interaction. While currently […]<\/p>\n","protected":false},"author":25,"featured_media":31226,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_price":"","_stock":"","_tribe_ticket_header":"","_tribe_default_ticket_provider":"","_ticket_start_date":"","_ticket_end_date":"","_tribe_ticket_show_description":"","_tribe_ticket_show_not_going":false,"_tribe_ticket_use_global_stock":"","_tribe_ticket_global_stock_level":"","_global_stock_mode":"","_global_stock_cap":"","_tribe_rsvp_for_event":"","_tribe_ticket_going_count":"","_tribe_ticket_not_going_count":"","_tribe_tickets_list":"[]","_tribe_ticket_has_attendee_info_fields":false,"footnotes":""},"categories":[18],"tags":[],"class_list":["post-31238","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","post_series-signal-forms-en"],"acf":[],"yoast_head":"\nAngular Signal Forms - Everything You Need to Know - ANGULARarchitects<\/title>\n<meta name=\"description\" content=\"All about Angular Signal Forms: Custom Validation, Schemas, Nested Forms, Form Array and Form Control, Metadata, Debouncing, Custom Controls\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Angular Signal Forms - Everything You Need to Know - ANGULARarchitects\" \/>\n<meta property=\"og:description\" content=\"All about Angular Signal Forms: Custom Validation, Schemas, Nested Forms, Form Array and Form Control, Metadata, Debouncing, Custom Controls\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/\" \/>\n<meta property=\"og:site_name\" content=\"ANGULARarchitects\" \/>\n<meta property=\"article:published_time\" content=\"2026-01-22T20:00:49+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-02-14T12:24:37+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2025\/09\/sujet-1-1024x536.png\" \/>\n<meta name=\"author\" content=\"Manfred Steyer\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:image\" content=\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2025\/09\/sujet-1-1024x536.png\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Manfred Steyer\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"36 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/\"},\"author\":{\"name\":\"Manfred Steyer\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#\/schema\/person\/f3de69c1e2bdb5ba04d8d2f5f998b81a\"},\"headline\":\"Angular Signal Forms – Everything You Need to Know\",\"datePublished\":\"2026-01-22T20:00:49+00:00\",\"dateModified\":\"2026-02-14T12:24:37+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/\"},\"wordCount\":3772,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#organization\"},\"image\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2025\/09\/shutterstock_2631518239.jpg\",\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/\",\"url\":\"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/\",\"name\":\"Angular Signal Forms - Everything You Need to Know - ANGULARarchitects\",\"isPartOf\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2025\/09\/shutterstock_2631518239.jpg\",\"datePublished\":\"2026-01-22T20:00:49+00:00\",\"dateModified\":\"2026-02-14T12:24:37+00:00\",\"description\":\"All about Angular Signal Forms: Custom Validation, Schemas, Nested Forms, Form Array and Form Control, Metadata, Debouncing, Custom Controls\",\"breadcrumb\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/#primaryimage\",\"url\":\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2025\/09\/shutterstock_2631518239.jpg\",\"contentUrl\":\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2025\/09\/shutterstock_2631518239.jpg\",\"width\":1000,\"height\":677},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.angulararchitects.io\/en\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Angular Signal Forms – Everything You Need to Know\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#website\",\"url\":\"https:\/\/www.angulararchitects.io\/en\/\",\"name\":\"ANGULARarchitects\",\"description\":\"AngularArchitects.io\",\"publisher\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.angulararchitects.io\/en\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#organization\",\"name\":\"ANGULARarchitects\",\"alternateName\":\"SOFTWAREarchitects\",\"url\":\"https:\/\/www.angulararchitects.io\/en\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2023\/07\/AA-Logo-RGB-horizontal-inside-knowledge-black.svg\",\"contentUrl\":\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2023\/07\/AA-Logo-RGB-horizontal-inside-knowledge-black.svg\",\"width\":644,\"height\":216,\"caption\":\"ANGULARarchitects\"},\"image\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/github.com\/angular-architects\",\"https:\/\/www.linkedin.com\/company\/angular-architects\/\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#\/schema\/person\/f3de69c1e2bdb5ba04d8d2f5f998b81a\",\"name\":\"Manfred Steyer\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/8778dfb353992fa3a0d909beee085a088891e5bfce65cdb3631801da527cf11b?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/8778dfb353992fa3a0d909beee085a088891e5bfce65cdb3631801da527cf11b?s=96&d=mm&r=g\",\"caption\":\"Manfred Steyer\"}}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Angular Signal Forms - Everything You Need to Know - ANGULARarchitects","description":"All about Angular Signal Forms: Custom Validation, Schemas, Nested Forms, Form Array and Form Control, Metadata, Debouncing, Custom Controls","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/","og_locale":"en_US","og_type":"article","og_title":"Angular Signal Forms - Everything You Need to Know - ANGULARarchitects","og_description":"All about Angular Signal Forms: Custom Validation, Schemas, Nested Forms, Form Array and Form Control, Metadata, Debouncing, Custom Controls","og_url":"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/","og_site_name":"ANGULARarchitects","article_published_time":"2026-01-22T20:00:49+00:00","article_modified_time":"2026-02-14T12:24:37+00:00","og_image":[{"url":"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2025\/09\/sujet-1-1024x536.png","type":"","width":"","height":""}],"author":"Manfred Steyer","twitter_card":"summary_large_image","twitter_image":"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2025\/09\/sujet-1-1024x536.png","twitter_misc":{"Written by":"Manfred Steyer","Est. reading time":"36 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/#article","isPartOf":{"@id":"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/"},"author":{"name":"Manfred Steyer","@id":"https:\/\/www.angulararchitects.io\/en\/#\/schema\/person\/f3de69c1e2bdb5ba04d8d2f5f998b81a"},"headline":"Angular Signal Forms – Everything You Need to Know","datePublished":"2026-01-22T20:00:49+00:00","dateModified":"2026-02-14T12:24:37+00:00","mainEntityOfPage":{"@id":"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/"},"wordCount":3772,"commentCount":0,"publisher":{"@id":"https:\/\/www.angulararchitects.io\/en\/#organization"},"image":{"@id":"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/#primaryimage"},"thumbnailUrl":"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2025\/09\/shutterstock_2631518239.jpg","inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/","url":"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/","name":"Angular Signal Forms - Everything You Need to Know - ANGULARarchitects","isPartOf":{"@id":"https:\/\/www.angulararchitects.io\/en\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/#primaryimage"},"image":{"@id":"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/#primaryimage"},"thumbnailUrl":"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2025\/09\/shutterstock_2631518239.jpg","datePublished":"2026-01-22T20:00:49+00:00","dateModified":"2026-02-14T12:24:37+00:00","description":"All about Angular Signal Forms: Custom Validation, Schemas, Nested Forms, Form Array and Form Control, Metadata, Debouncing, Custom Controls","breadcrumb":{"@id":"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/#primaryimage","url":"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2025\/09\/shutterstock_2631518239.jpg","contentUrl":"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2025\/09\/shutterstock_2631518239.jpg","width":1000,"height":677},{"@type":"BreadcrumbList","@id":"https:\/\/www.angulararchitects.io\/en\/blog\/all-about-angulars-new-signal-forms\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.angulararchitects.io\/en\/"},{"@type":"ListItem","position":2,"name":"Angular Signal Forms – Everything You Need to Know"}]},{"@type":"WebSite","@id":"https:\/\/www.angulararchitects.io\/en\/#website","url":"https:\/\/www.angulararchitects.io\/en\/","name":"ANGULARarchitects","description":"AngularArchitects.io","publisher":{"@id":"https:\/\/www.angulararchitects.io\/en\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.angulararchitects.io\/en\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.angulararchitects.io\/en\/#organization","name":"ANGULARarchitects","alternateName":"SOFTWAREarchitects","url":"https:\/\/www.angulararchitects.io\/en\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.angulararchitects.io\/en\/#\/schema\/logo\/image\/","url":"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2023\/07\/AA-Logo-RGB-horizontal-inside-knowledge-black.svg","contentUrl":"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2023\/07\/AA-Logo-RGB-horizontal-inside-knowledge-black.svg","width":644,"height":216,"caption":"ANGULARarchitects"},"image":{"@id":"https:\/\/www.angulararchitects.io\/en\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/github.com\/angular-architects","https:\/\/www.linkedin.com\/company\/angular-architects\/"]},{"@type":"Person","@id":"https:\/\/www.angulararchitects.io\/en\/#\/schema\/person\/f3de69c1e2bdb5ba04d8d2f5f998b81a","name":"Manfred Steyer","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.angulararchitects.io\/en\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/8778dfb353992fa3a0d909beee085a088891e5bfce65cdb3631801da527cf11b?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/8778dfb353992fa3a0d909beee085a088891e5bfce65cdb3631801da527cf11b?s=96&d=mm&r=g","caption":"Manfred Steyer"}}]}},"_links":{"self":[{"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/posts\/31238","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/users\/25"}],"replies":[{"embeddable":true,"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/comments?post=31238"}],"version-history":[{"count":10,"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/posts\/31238\/revisions"}],"predecessor-version":[{"id":32666,"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/posts\/31238\/revisions\/32666"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/media\/31226"}],"wp:attachment":[{"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/media?parent=31238"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/categories?post=31238"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/tags?post=31238"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}