FormControlDirectivelink

说明link

This directive ensures that any values written to the FormControl instance programmatically will be written to the DOM element (model -> view). Conversely, any values written to the DOM element through user input will be reflected in the FormControl instance (view -> model).

Use this directive if you'd like to create and manage a FormControl instance directly. Simply create a FormControl, save it to your component class, and pass it into the FormControlDirective.

This directive is designed to be used as a standalone control. Unlike FormControlName, it does not require that your FormControl instance be part of any parent FormGroup, and it won't be registered to any FormGroupDirective that exists above it.

Get the value: the value property is always synced and available on the FormControl instance. See a full list of available properties in AbstractControl.

Set the value: You can pass in an initial value when instantiating the FormControl, or you can set it programmatically later using setValue or patchValue.

Listen to value: If you want to listen to changes in the value of the control, you can subscribe to the valueChanges event. You can also listen to statusChanges to be notified when the validation status is re-calculated.

Examplelink

• npm package: @angular/forms

• NgModule: ReactiveFormsModule

Use with ngModellink

Support for using the ngModel input property and ngModelChange event with reactive form directives has been deprecated in Angular v6 and will be removed in Angular v7.

Now deprecated:

This has been deprecated for a few reasons. First, developers have found this pattern confusing. It seems like the actual ngModel directive is being used, but in fact it's an input/output property named ngModel on the reactive form directive that simply approximates (some of) its behavior. Specifically, it allows getting/setting the value and intercepting value events. However, some of ngModel's other features - like delaying updates withngModelOptions or exporting the directive - simply don't work, which has understandably caused some confusion.

In addition, this pattern mixes template-driven and reactive forms strategies, which we generally don't recommend because it doesn't take advantage of the full benefits of either strategy. Setting the value in the template violates the template-agnostic principles behind reactive forms, whereas adding a FormControl/FormGroup layer in the class removes the convenience of defining forms in the template.

To update your code before v7, you'll want to decide whether to stick with reactive form directives (and get/set values using reactive forms patterns) or switch over to template-driven directives.

After (choice 1 - use reactive forms):

After (choice 2 - use template-driven forms):

By default, when you use this pattern, you will see a deprecation warning once in dev mode. You can choose to silence this warning by providing a config for ReactiveFormsModule at import time:

Alternatively, you can choose to surface a separate warning for each instance of this pattern with a config value of "always". This may help to track down where in the code the pattern is being used as the code is being updated.