docs: refactor forms overview (#36919)
Reorganize and edit content of existing form overview to conform to current doc standards and styles PR Close #36919
|
@ -4,22 +4,27 @@ Handling user input with forms is the cornerstone of many common applications. A
|
||||||
|
|
||||||
Angular provides two different approaches to handling user input through forms: reactive and template-driven. Both capture user input events from the view, validate the user input, create a form model and data model to update, and provide a way to track changes.
|
Angular provides two different approaches to handling user input through forms: reactive and template-driven. Both capture user input events from the view, validate the user input, create a form model and data model to update, and provide a way to track changes.
|
||||||
|
|
||||||
Reactive and template-driven forms process and manage form data differently. Each offers different advantages.
|
|
||||||
|
|
||||||
**In general:**
|
|
||||||
|
|
||||||
* **Reactive forms** are more robust: they're more scalable, reusable, and testable. If forms are a key part of your application, or you're already using reactive patterns for building your application, use reactive forms.
|
|
||||||
* **Template-driven forms** are useful for adding a simple form to an app, such as an email list signup form. They're easy to add to an app, but they don't scale as well as reactive forms. If you have very basic form requirements and logic that can be managed solely in the template, use template-driven forms.
|
|
||||||
|
|
||||||
This guide provides information to help you decide which type of form works best for your situation. It introduces the common building blocks used by both approaches. It also summarizes the key differences between the two approaches, and demonstrates those differences in the context of setup, data flow, and testing.
|
This guide provides information to help you decide which type of form works best for your situation. It introduces the common building blocks used by both approaches. It also summarizes the key differences between the two approaches, and demonstrates those differences in the context of setup, data flow, and testing.
|
||||||
|
|
||||||
<div class="alert is-helpful">
|
## Prerequisites
|
||||||
|
|
||||||
**Note:** For complete information about each kind of form, see [Reactive Forms](guide/reactive-forms) and [Template-driven Forms](guide/forms).
|
This guide assumes that you have a basic understanding of the following.
|
||||||
|
|
||||||
</div>
|
* [TypeScript](https://www.typescriptlang.org/docs/home.html "The TypeScript language") and HTML5 programming.
|
||||||
|
|
||||||
## Key differences
|
* Angular app-design fundamentals, as described in [Angular Concepts](guide/architecture "Introduction to Angular concepts.").
|
||||||
|
|
||||||
|
* The basics of [Angular template syntax](guide/architecture-components#template-syntax "Template syntax intro").
|
||||||
|
|
||||||
|
## Choosing an approach
|
||||||
|
|
||||||
|
Reactive forms and template-driven forms process and manage form data differently. Each approach offers different advantages.
|
||||||
|
|
||||||
|
* **Reactive forms** provide direct, explicit access to the underlying forms object model. Compared to template-driven forms, they are more robust: they're more scalable, reusable, and testable. If forms are a key part of your application, or you're already using reactive patterns for building your application, use reactive forms.
|
||||||
|
|
||||||
|
* **Template-driven forms** rely on directives in the template to create and manipulate the underlying object model. They are useful for adding a simple form to an app, such as an email list signup form. They're easy to add to an app, but they don't scale as well as reactive forms. If you have very basic form requirements and logic that can be managed solely in the template, template-driven forms could be a good fit.
|
||||||
|
|
||||||
|
### Key differences
|
||||||
|
|
||||||
The table below summarizes the key differences between reactive and template-driven forms.
|
The table below summarizes the key differences between reactive and template-driven forms.
|
||||||
|
|
||||||
|
@ -30,17 +35,33 @@ The table below summarizes the key differences between reactive and template-dri
|
||||||
|
|
||||||
||Reactive|Template-driven|
|
||Reactive|Template-driven|
|
||||||
|--- |--- |--- |
|
|--- |--- |--- |
|
||||||
|Setup (form model)|More explicit, created in component class|Less explicit, created by directives|
|
|[Setup of form model](#setup) | Explicit, created in component class | Implicit, created by directives |
|
||||||
|Data model|Structured|Unstructured|
|
|[Data model](#data-flow-in-forms) | Structured and immutable | Unstructured and mutable |
|
||||||
|Predictability | Synchronous | Asynchronous |
|
|Predictability | Synchronous | Asynchronous |
|
||||||
|Form validation|Functions|Directives|
|
|[Form validation](#validation) | Functions | Directives |
|
||||||
|Mutability|Immutable|Mutable|
|
|
||||||
|Scalability|Low-level API access|Abstraction on top of APIs|
|
|
||||||
|
|
||||||
## Common foundation
|
### Scalability
|
||||||
|
|
||||||
Both reactive and template-driven forms share underlying building blocks.
|
If forms are a central part of your application, scalability is very important. Being able to reuse form models across components is critical.
|
||||||
|
|
||||||
|
Reactive forms are more scalable than template-driven forms. They provide direct access to the underlying form API, and synchronous access to the form data model, making creating large-scale forms easier.
|
||||||
|
Reactive forms require less setup for testing, and testing does not require deep understanding of change detection to properly test form updates and validation.
|
||||||
|
|
||||||
|
Template-driven forms focus on simple scenarios and are not as reusable.
|
||||||
|
They abstract away the underlying form API, and provide only asynchronous access to the form data model.
|
||||||
|
The abstraction of template-driven forms also affects testing.
|
||||||
|
Tests are deeply reliant on manual change detection execution to run properly, and require more setup.
|
||||||
|
|
||||||
|
{@a setup}
|
||||||
|
|
||||||
|
## Setting up the form model
|
||||||
|
|
||||||
|
Both reactive and template-driven forms track value changes between the form input elements that users interact with and the form data in your component model.
|
||||||
|
The two approaches share underlying building blocks, but differ in how you create and manage the common form-control instances.
|
||||||
|
|
||||||
|
### Common form foundation classes
|
||||||
|
|
||||||
|
Both reactive and template-driven forms are built on the following base classes.
|
||||||
|
|
||||||
* `FormControl` tracks the value and validation status of an individual form control.
|
* `FormControl` tracks the value and validation status of an individual form control.
|
||||||
|
|
||||||
|
@ -50,59 +71,59 @@ Both reactive and template-driven forms share underlying building blocks.
|
||||||
|
|
||||||
* `ControlValueAccessor` creates a bridge between Angular `FormControl` instances and native DOM elements.
|
* `ControlValueAccessor` creates a bridge between Angular `FormControl` instances and native DOM elements.
|
||||||
|
|
||||||
See the [Form model setup](#setup-the-form-model) section below for an introduction to how these control instances are created and managed with reactive and template-driven forms. Further details are provided in the [data flow section](#data-flow-in-forms) of this guide.
|
|
||||||
|
|
||||||
{@a setup-the-form-model}
|
{@a setup-the-form-model}
|
||||||
|
|
||||||
## Form model setup
|
|
||||||
|
|
||||||
Reactive and template-driven forms both use a form model to track value changes between Angular forms and form input elements. The examples below show how the form model is defined and created.
|
|
||||||
|
|
||||||
### Setup in reactive forms
|
### Setup in reactive forms
|
||||||
|
|
||||||
Here's a component with an input field for a single control implemented using reactive forms.
|
With reactive forms, you define the form model directly in the component class.
|
||||||
|
The `[formControl]` directive links the explicitly created `FormControl` instance to a specific form element in the view, using an internal value accessor.
|
||||||
|
|
||||||
|
The following component implements an input field for a single control, using reactive forms. In this example, the form model is the `FormControl` instance.
|
||||||
|
|
||||||
<code-example path="forms-overview/src/app/reactive/favorite-color/favorite-color.component.ts">
|
<code-example path="forms-overview/src/app/reactive/favorite-color/favorite-color.component.ts">
|
||||||
</code-example>
|
</code-example>
|
||||||
|
|
||||||
The source of truth provides the value and status of the form element at a given point in time. In reactive forms, the form model is the source of truth. In the example above, the form model is the `FormControl` instance.
|
Figure 1 shows how, in reactive forms, the form model is the source of truth; it provides the value and status of the form element at any given point in time, through the `[formControl]` directive on the input element.
|
||||||
|
|
||||||
|
**Figure 1.** *Direct access to forms model in a reactive form.*
|
||||||
|
|
||||||
<div class="lightbox">
|
<div class="lightbox">
|
||||||
<img src="generated/images/guide/forms-overview/key-diff-reactive-forms.png" alt="Reactive forms key differences">
|
<img src="generated/images/guide/forms-overview/key-diff-reactive-forms.png" alt="Reactive forms key differences">
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
With reactive forms, the form model is explicitly defined in the component class. The reactive form directive (in this case, `FormControlDirective`) then links the existing `FormControl` instance to a specific form element in the view using a value accessor (`ControlValueAccessor` instance).
|
|
||||||
|
|
||||||
### Setup in template-driven forms
|
### Setup in template-driven forms
|
||||||
|
|
||||||
Here's the same component with an input field for a single control implemented using template-driven forms.
|
In template-driven forms, the form model is implicit, rather than explicit. The directive `NgModel` creates and manages a `FormControl` instance for a given form element.
|
||||||
|
|
||||||
|
The following component implements the same input field for a single control, using template-driven forms.
|
||||||
|
|
||||||
<code-example path="forms-overview/src/app/template/favorite-color/favorite-color.component.ts">
|
<code-example path="forms-overview/src/app/template/favorite-color/favorite-color.component.ts">
|
||||||
</code-example>
|
</code-example>
|
||||||
|
|
||||||
In template-driven forms, the source of truth is the template.
|
In a template-driven form the source of truth is the template. You do not have direct programmatic access to the `FormControl` instance, as shown in Figure 2.
|
||||||
|
|
||||||
|
**Figure 2.** *Indirect access to forms model in a template-driven form.*
|
||||||
|
|
||||||
<div class="lightbox">
|
<div class="lightbox">
|
||||||
<img src="generated/images/guide/forms-overview/key-diff-td-forms.png" alt="Template-driven forms key differences">
|
<img src="generated/images/guide/forms-overview/key-diff-td-forms.png" alt="Template-driven forms key differences">
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
The abstraction of the form model promotes simplicity over structure. The template-driven form directive `NgModel` is responsible for creating and managing the `FormControl` instance for a given form element. It's less explicit, but you no longer have direct control over the form model.
|
|
||||||
|
|
||||||
{@a data-flow-in-forms}
|
{@a data-flow-in-forms}
|
||||||
|
|
||||||
## Data flow in forms
|
## Data flow in forms
|
||||||
|
|
||||||
When building forms in Angular, it's important to understand how the framework handles data flowing from the user or from programmatic changes. Reactive and template-driven forms follow two different strategies when handling form input. The data flow examples below begin with the favorite color input field example from above, and then show how changes to favorite color are handled in reactive forms compared to template-driven forms.
|
When an application contains a form, Angular must keep the view in sync with the component model and the component model in sync with the view.
|
||||||
|
As users change values and make selections through the view, the new values must be reflected in the data model.
|
||||||
|
Similarly, when the program logic changes values in the data model, those values must be reflected in the view.
|
||||||
|
|
||||||
|
Reactive and template-driven forms differ in how they handle data flowing from the user or from programmatic changes.
|
||||||
|
The following diagrams illustrate both kinds of data flow for each type of form, using the a favorite-color input field defined above.
|
||||||
|
|
||||||
### Data flow in reactive forms
|
### Data flow in reactive forms
|
||||||
|
|
||||||
As described above, in reactive forms each form element in the view is directly linked to a form model (`FormControl` instance). Updates from the view to the model and from the model to the view are synchronous and aren't dependent on the UI rendered. The diagrams below use the same favorite color example to demonstrate how data flows when an input field's value is changed from the view and then from the model.
|
In reactive forms each form element in the view is directly linked to the form model (a `FormControl` instance). Updates from the view to the model and from the model to the view are synchronous and do not depend on how the UI is rendered.
|
||||||
|
|
||||||
<div class="lightbox">
|
The view-to-model diagram shows how data flows when an input field's value is changed from the view through the following steps.
|
||||||
<img src="generated/images/guide/forms-overview/dataflow-reactive-forms-vtm.png" alt="Reactive forms data flow - view to model" width="100%">
|
|
||||||
</div>
|
|
||||||
|
|
||||||
The steps below outline the data flow from view to model.
|
|
||||||
|
|
||||||
1. The user types a value into the input element, in this case the favorite color *Blue*.
|
1. The user types a value into the input element, in this case the favorite color *Blue*.
|
||||||
1. The form input element emits an "input" event with the latest value.
|
1. The form input element emits an "input" event with the latest value.
|
||||||
|
@ -111,25 +132,25 @@ The steps below outline the data flow from view to model.
|
||||||
1. Any subscribers to the `valueChanges` observable receive the new value.
|
1. Any subscribers to the `valueChanges` observable receive the new value.
|
||||||
|
|
||||||
<div class="lightbox">
|
<div class="lightbox">
|
||||||
<img src="generated/images/guide/forms-overview/dataflow-reactive-forms-mtv.png" alt="Reactive forms data flow - model to view" width="100%">
|
<img src="generated/images/guide/forms-overview/dataflow-reactive-forms-vtm.png" alt="Reactive forms data flow - view to model">
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
The steps below outline the data flow from model to view.
|
The model-to-view diagram shows how a programmatic change to the model is propagated to the view through the following steps.
|
||||||
|
|
||||||
1. The user calls the `favoriteColorControl.setValue()` method, which updates the `FormControl` value.
|
1. The user calls the `favoriteColorControl.setValue()` method, which updates the `FormControl` value.
|
||||||
1. The `FormControl` instance emits the new value through the `valueChanges` observable.
|
1. The `FormControl` instance emits the new value through the `valueChanges` observable.
|
||||||
1. Any subscribers to the `valueChanges` observable receive the new value.
|
1. Any subscribers to the `valueChanges` observable receive the new value.
|
||||||
1. The control value accessor on the form input element updates the element with the new value.
|
1. The control value accessor on the form input element updates the element with the new value.
|
||||||
|
|
||||||
### Data flow in template-driven forms
|
|
||||||
|
|
||||||
In template-driven forms, each form element is linked to a directive that manages the form model internally. The diagrams below use the same favorite color example to demonstrate how data flows when an input field's value is changed from the view and then from the model.
|
|
||||||
|
|
||||||
<div class="lightbox">
|
<div class="lightbox">
|
||||||
<img src="generated/images/guide/forms-overview/dataflow-td-forms-vtm.png" alt="Template-driven forms data flow - view to model" width="100%">
|
<img src="generated/images/guide/forms-overview/dataflow-reactive-forms-mtv.png" alt="Reactive forms data flow - model to view">
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
The steps below outline the data flow from view to model when the input value changes from *Red* to *Blue*.
|
### Data flow in template-driven forms
|
||||||
|
|
||||||
|
In template-driven forms, each form element is linked to a directive that manages the form model internally.
|
||||||
|
|
||||||
|
The view-to-model diagram shows how data flows when an input field's value is changed from the view through the following steps.
|
||||||
|
|
||||||
1. The user types *Blue* into the input element.
|
1. The user types *Blue* into the input element.
|
||||||
1. The input element emits an "input" event with the value *Blue*.
|
1. The input element emits an "input" event with the value *Blue*.
|
||||||
|
@ -141,10 +162,10 @@ The steps below outline the data flow from view to model when the input value ch
|
||||||
is updated to the value emitted by the `ngModelChange` event (*Blue*).
|
is updated to the value emitted by the `ngModelChange` event (*Blue*).
|
||||||
|
|
||||||
<div class="lightbox">
|
<div class="lightbox">
|
||||||
<img src="generated/images/guide/forms-overview/dataflow-td-forms-mtv.png" alt="Template-driven forms data flow - model to view" width="100%">
|
<img src="generated/images/guide/forms-overview/dataflow-td-forms-vtm.png" alt="Template-driven forms data flow - view to model" width="100%">
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
The steps below outline the data flow from model to view when the `favoriteColor` changes from *Blue* to *Red*.
|
The model-to-view diagram shows how data flows from model to view when the `favoriteColor` changes from *Blue* to *Red*, through the following steps
|
||||||
|
|
||||||
1. The `favoriteColor` value is updated in the component.
|
1. The `favoriteColor` value is updated in the component.
|
||||||
1. Change detection begins.
|
1. Change detection begins.
|
||||||
|
@ -156,6 +177,30 @@ The steps below outline the data flow from model to view when the `favoriteColor
|
||||||
1. Any subscribers to the `valueChanges` observable receive the new value.
|
1. Any subscribers to the `valueChanges` observable receive the new value.
|
||||||
1. The control value accessor updates the form input element in the view with the latest `favoriteColor` value.
|
1. The control value accessor updates the form input element in the view with the latest `favoriteColor` value.
|
||||||
|
|
||||||
|
<div class="lightbox">
|
||||||
|
<img src="generated/images/guide/forms-overview/dataflow-td-forms-mtv.png" alt="Template-driven forms data flow - model to view" width="100%">
|
||||||
|
</div>
|
||||||
|
|
||||||
|
### Mutability of the data model
|
||||||
|
|
||||||
|
The change-tracking method plays a role in the efficiency of your application.
|
||||||
|
|
||||||
|
* **Reactive forms** keep the data model pure by providing it as an immutable data structure.
|
||||||
|
Each time a change is triggered on the data model, the `FormControl` instance returns a new data model rather than updating the existing data model.
|
||||||
|
This gives you the ability to track unique changes to the data model through the control's observable.
|
||||||
|
Change detection is more efficient because it only needs to update on unique changes.
|
||||||
|
Because data updates follow reactive patterns, you can integrate with observable operators to transform data.
|
||||||
|
|
||||||
|
* **Template-driven** forms rely on mutability with two-way data binding to update the data model in the component as changes are made in the template.
|
||||||
|
Because there are no unique changes to track on the data model when using two-way data binding, change detection is less efficient at determining when updates are required.
|
||||||
|
|
||||||
|
The difference is demonstrated in the previous examples that use the favorite-color input element.
|
||||||
|
|
||||||
|
* With reactive forms, the **`FormControl` instance** always returns a new value when the control's value is updated.
|
||||||
|
|
||||||
|
* With template-driven forms, the **favorite color property** is always modified to its new value.
|
||||||
|
|
||||||
|
{@a validation}
|
||||||
## Form validation
|
## Form validation
|
||||||
|
|
||||||
Validation is an integral part of managing any set of forms. Whether you're checking for required fields or querying an external API for an existing username, Angular provides a set of built-in validators as well as the ability to create custom validators.
|
Validation is an integral part of managing any set of forms. Whether you're checking for required fields or querying an external API for an existing username, Angular provides a set of built-in validators as well as the ability to create custom validators.
|
||||||
|
@ -167,36 +212,37 @@ For more information, see [Form Validation](guide/form-validation).
|
||||||
|
|
||||||
## Testing
|
## Testing
|
||||||
|
|
||||||
Testing plays a large part in complex applications and a simpler testing strategy is useful when validating that your forms function correctly. Reactive forms and template-driven forms have different levels of reliance on rendering the UI to perform assertions based on form control and form field changes. The following examples demonstrate the process of testing forms with reactive and template-driven forms.
|
Testing plays a large part in complex applications. A simpler testing strategy is useful when validating that your forms function correctly.
|
||||||
|
Reactive forms and template-driven forms have different levels of reliance on rendering the UI to perform assertions based on form control and form field changes.
|
||||||
|
The following examples demonstrate the process of testing forms with reactive and template-driven forms.
|
||||||
|
|
||||||
### Testing reactive forms
|
### Testing reactive forms
|
||||||
|
|
||||||
Reactive forms provide a relatively easy testing strategy because they provide synchronous access to the form and data models, and they can be tested without rendering the UI. In these tests, status and data are queried and manipulated through the control without interacting with the change detection cycle.
|
Reactive forms provide a relatively easy testing strategy because they provide synchronous access to the form and data models, and they can be tested without rendering the UI.
|
||||||
|
In these tests, status and data are queried and manipulated through the control without interacting with the change detection cycle.
|
||||||
|
|
||||||
The following tests use the favorite color components mentioned earlier to verify the data flows from view to model and model to view for a reactive form.
|
The following tests use the favorite-color components from previous examples to verify the view-to-model and model-to-view data flows for a reactive form.
|
||||||
|
|
||||||
The following test verifies the data flow from view to model.
|
**Verifying view-to-model data flow**
|
||||||
|
|
||||||
<code-example path="forms-overview/src/app/reactive/favorite-color/favorite-color.component.spec.ts" region="view-to-model" header="Favorite color test - view to model">
|
The first example performs the following steps to verify the view-to-model data flow.
|
||||||
</code-example>
|
|
||||||
|
|
||||||
Here are the steps performed in the view to model test.
|
|
||||||
|
|
||||||
1. Query the view for the form input element, and create a custom "input" event for the test.
|
1. Query the view for the form input element, and create a custom "input" event for the test.
|
||||||
1. Set the new value for the input to *Red*, and dispatch the "input" event on the form input element.
|
1. Set the new value for the input to *Red*, and dispatch the "input" event on the form input element.
|
||||||
1. Assert that the component's `favoriteColorControl` value matches the value from the input.
|
1. Assert that the component's `favoriteColorControl` value matches the value from the input.
|
||||||
|
|
||||||
The following test verifies the data flow from model to view.
|
<code-example path="forms-overview/src/app/reactive/favorite-color/favorite-color.component.spec.ts" region="view-to-model" header="Favorite color test - view to model">
|
||||||
|
|
||||||
<code-example path="forms-overview/src/app/reactive/favorite-color/favorite-color.component.spec.ts" region="model-to-view" header="Favorite color test - model to view">
|
|
||||||
</code-example>
|
</code-example>
|
||||||
|
|
||||||
Here are the steps performed in the model to view test.
|
The next example performs the following steps to verify the model-to-view data flow.
|
||||||
|
|
||||||
1. Use the `favoriteColorControl`, a `FormControl` instance, to set the new value.
|
1. Use the `favoriteColorControl`, a `FormControl` instance, to set the new value.
|
||||||
1. Query the view for the form input element.
|
1. Query the view for the form input element.
|
||||||
1. Assert that the new value set on the control matches the value in the input.
|
1. Assert that the new value set on the control matches the value in the input.
|
||||||
|
|
||||||
|
<code-example path="forms-overview/src/app/reactive/favorite-color/favorite-color.component.spec.ts" region="model-to-view" header="Favorite color test - model to view">
|
||||||
|
</code-example>
|
||||||
|
|
||||||
### Testing template-driven forms
|
### Testing template-driven forms
|
||||||
|
|
||||||
Writing tests with template-driven forms requires a detailed knowledge of the change detection process and an understanding of how directives run on each cycle to ensure that elements are queried, tested, or changed at the correct time.
|
Writing tests with template-driven forms requires a detailed knowledge of the change detection process and an understanding of how directives run on each cycle to ensure that elements are queried, tested, or changed at the correct time.
|
||||||
|
@ -228,46 +274,16 @@ Here are the steps performed in the model to view test.
|
||||||
1. Query the view for the form input element.
|
1. Query the view for the form input element.
|
||||||
1. Assert that the input value matches the value of the `favoriteColor` property in the component instance.
|
1. Assert that the input value matches the value of the `favoriteColor` property in the component instance.
|
||||||
|
|
||||||
## Mutability
|
|
||||||
|
|
||||||
The change tracking method plays a role in the efficiency of your application.
|
|
||||||
|
|
||||||
|
|
||||||
* **Reactive forms** keep the data model pure by providing it as an immutable data structure. Each time a change is triggered on the data model, the `FormControl` instance returns a new data model rather than updating the existing data model. This gives you the ability to track unique changes to the data model through the control's observable. This provides one way for change detection to be more efficient because it only needs to update on unique changes. It also follows reactive patterns that integrate with observable operators to transform data.
|
|
||||||
|
|
||||||
* **Template-driven** forms rely on mutability with two-way data binding to update the data model in the component as changes are made in the template. Because there are no unique changes to track on the data model when using two-way data binding, change detection is less efficient at determining when updates are required.
|
|
||||||
|
|
||||||
The difference is demonstrated in the examples above using the **favorite color** input element.
|
|
||||||
|
|
||||||
|
|
||||||
* With reactive forms, the **`FormControl` instance** always returns a new value when the control's value is updated.
|
|
||||||
|
|
||||||
* With template-driven forms, the **favorite color property** is always modified to its new value.
|
|
||||||
|
|
||||||
## Scalability
|
|
||||||
|
|
||||||
If forms are a central part of your application, scalability is very important. Being able to reuse form models across components is critical.
|
|
||||||
|
|
||||||
|
|
||||||
* **Reactive forms** provide access to low-level APIs and synchronous access to the form model, making creating large-scale forms easier.
|
|
||||||
|
|
||||||
* **Template-driven** forms focus on simple scenarios, are not as reusable, abstract away the low-level APIs, and provide asynchronous access to the form model. The abstraction with template-driven forms also surfaces in testing, where testing reactive forms requires less setup and no dependence on the change detection cycle when updating and validating the form and data models during testing.
|
|
||||||
|
|
||||||
## Final thoughts
|
|
||||||
|
|
||||||
Choosing a strategy begins with understanding the strengths and weaknesses of the options presented. Low-level API and form model access, predictability, mutability, straightforward validation and testing strategies, and scalability are all important considerations in choosing the infrastructure you use to build your forms in Angular. Template-driven forms are similar to patterns in AngularJS, but they have limitations given the criteria of many modern, large-scale Angular apps. Reactive forms minimize these limitations. Reactive forms integrate with reactive patterns already present in other areas of the Angular architecture, and complement those requirements well.
|
|
||||||
|
|
||||||
## Next steps
|
## Next steps
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
To learn more about reactive forms, see the following guides:
|
To learn more about reactive forms, see the following guides:
|
||||||
|
|
||||||
* [Reactive Forms](guide/reactive-forms)
|
* [Reactive forms](guide/reactive-forms) guide
|
||||||
* [Form Validation](guide/form-validation#reactive-form-validation)
|
* [Form validation](guide/form-validation#reactive-form-validation) guide
|
||||||
* [Dynamic Forms](guide/dynamic-form)
|
* [Building dynamic forms](guide/dynamic-form) tutorial
|
||||||
|
|
||||||
To learn more about template-driven forms, see the following guides:
|
To learn more about template-driven forms, see the following guides:
|
||||||
|
|
||||||
* [Template-driven Forms](guide/forms#template-driven-forms)
|
* [Building a template-driven form](guide/forms#template-driven-forms) tutorial
|
||||||
* [Form Validation](guide/form-validation#template-driven-validation)
|
* [Form validation](guide/form-validation#template-driven-validation) guide
|
||||||
|
|
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 56 KiB |
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 57 KiB |
Before Width: | Height: | Size: 26 KiB After Width: | Height: | Size: 44 KiB |
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 39 KiB |