{ "id": "guide/forms-overview", "title": "Introduction to forms in Angular", "contents": "\n\n\n
Handling user input with forms is the cornerstone of many common applications. Applications use forms to enable users to log in, to update a profile, to enter sensitive information, and to perform many other data-entry tasks.
\nAngular 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.
\nThis 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.
\nThis guide assumes that you have a basic understanding of the following.
\nTypeScript and HTML5 programming.
\nAngular app-design fundamentals, as described in Angular Concepts.
\nThe basics of Angular template syntax.
\nReactive forms and template-driven forms process and manage form data differently. Each approach offers different advantages.
\nReactive 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.
\nTemplate-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.
\nThe table below summarizes the key differences between reactive and template-driven forms.
\n\n\n | Reactive | \nTemplate-driven | \n
---|---|---|
Setup of form model | \nExplicit, created in component class | \nImplicit, created by directives | \n
Data model | \nStructured and immutable | \nUnstructured and mutable | \n
Predictability | \nSynchronous | \nAsynchronous | \n
Form validation | \nFunctions | \nDirectives | \n
If forms are a central part of your application, scalability is very important. Being able to reuse form models across components is critical.
\nReactive 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.\nReactive forms require less setup for testing, and testing does not require deep understanding of change detection to properly test form updates and validation.
\nTemplate-driven forms focus on simple scenarios and are not as reusable.\nThey abstract away the underlying form API, and provide only asynchronous access to the form data model.\nThe abstraction of template-driven forms also affects testing.\nTests are deeply reliant on manual change detection execution to run properly, and require more setup.
\n\nBoth 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.\nThe two approaches share underlying building blocks, but differ in how you create and manage the common form-control instances.
\nBoth reactive and template-driven forms are built on the following base classes.
\nFormControl
tracks the value and validation status of an individual form control.
FormGroup
tracks the same values and status for a collection of form controls.
FormArray
tracks the same values and status for an array of form controls.
ControlValueAccessor
creates a bridge between Angular FormControl
instances and native DOM elements.
With reactive forms, you define the form model directly in the component class.\nThe [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.
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.
\nIn 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.
\nIn 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.
\nWhen 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.\nAs users change values and make selections through the view, the new values must be reflected in the data model.\nSimilarly, when the program logic changes values in the data model, those values must be reflected in the view.
\nReactive and template-driven forms differ in how they handle data flowing from the user or from programmatic changes.\nThe following diagrams illustrate both kinds of data flow for each type of form, using the favorite-color input field defined above.
\nIn 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.
The view-to-model diagram shows how data flows when an input field's value is changed from the view through the following steps.
\nFormControl
instance.FormControl
instance emits the new value through the valueChanges
observable.valueChanges
observable receive the new value.The model-to-view diagram shows how a programmatic change to the model is propagated to the view through the following steps.
\nfavoriteColorControl.setValue()
method, which updates the FormControl
value.FormControl
instance emits the new value through the valueChanges
observable.valueChanges
observable receive the new value.In template-driven forms, each form element is linked to a directive that manages the form model internally.
\nThe view-to-model diagram shows how data flows when an input field's value is changed from the view through the following steps.
\nsetValue()
method on the FormControl
instance.FormControl
instance emits the new value through the valueChanges
observable.valueChanges
observable receive the new value.NgModel.viewToModelUpdate()
method which emits an ngModelChange
event.favoriteColor
property, the favoriteColor
property in the component\nis updated to the value emitted by the ngModelChange
event (Blue).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
favoriteColor
value is updated in the component.ngOnChanges
lifecycle hook is called on the NgModel
directive instance because the value of one of its inputs has changed.ngOnChanges()
method queues an async task to set the value for the internal FormControl
instance.FormControl
instance value is executed.FormControl
instance emits the latest value through the valueChanges
observable.valueChanges
observable receive the new value.favoriteColor
value.The change-tracking method plays a role in the efficiency of your application.
\nReactive forms keep the data model pure by providing it as an immutable data structure.\nEach time a change is triggered on the data model, the FormControl
instance returns a new data model rather than updating the existing data model.\nThis gives you the ability to track unique changes to the data model through the control's observable.\nChange detection is more efficient because it only needs to update on unique changes.\nBecause 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.\nBecause 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.
\nThe difference is demonstrated in the previous examples that use the favorite-color input element.
\nWith 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.
\nValidation 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.
\nFor more information, see Form Validation.
\nTesting plays a large part in complex applications. A simpler testing strategy is useful when validating that your forms function correctly.\nReactive 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.\nThe following examples demonstrate the process of testing forms with reactive and template-driven forms.
\nReactive 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.\nIn these tests, status and data are queried and manipulated through the control without interacting with the change detection cycle.
\nThe 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.
\nVerifying view-to-model data flow
\nThe first example performs the following steps to verify the view-to-model data flow.
\nfavoriteColorControl
value matches the value from the input.The next example performs the following steps to verify the model-to-view data flow.
\nfavoriteColorControl
, a FormControl
instance, to set the new value.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.
\nThe following tests use the favorite color components mentioned earlier to verify the data flows from view to model and model to view for a template-driven form.
\nThe following test verifies the data flow from view to model.
\nHere are the steps performed in the view to model test.
\nfavoriteColor
property value matches the value from the input.The following test verifies the data flow from model to view.
\nHere are the steps performed in the model to view test.
\nfavoriteColor
property.tick()
method to simulate the passage of time within the fakeAsync()
task.favoriteColor
property in the component instance.To learn more about reactive forms, see the following guides:
\n\nTo learn more about template-driven forms, see the following guides:
\nNgForm
directive API reference