前言

眾所周知Angular響應(yīng)式表單相比較模板驅(qū)動表單更大操作性、更易測試性。因此，我更推薦這類表單創(chuàng)造方式。

當(dāng)一個(gè)用于修改用戶信息的表單，數(shù)據(jù)的來源總是來自遠(yuǎn)程；而對于一個(gè) FormGroup 的創(chuàng)建總在 ngOnInit 中完成。因此，這里會有一個(gè)表單更新值的問題。

而通常我們會透過 FormGroup 下的三種方式 setValue、patchValue、reset 將值寫入表單當(dāng)中。

當(dāng)然，或許我說的這三種方式時(shí)你壓根就沒有做過，那說明在表單上你依賴的是雙向綁定 [(ngModel)]，這本身就不是符合 Angular 響應(yīng)式表單的牛B之處了。因此，在此我們不討論這種這種方式。下面來一起看看詳細(xì)的介紹：

一、創(chuàng)建響應(yīng)式表單

我們模擬一個(gè)用戶信息修改的表單所需要的字段，可能包括：email、nickname 等。

如果以API的方式與現(xiàn)實(shí)字段之間產(chǎn)生一個(gè)關(guān)聯(lián)，那么 FormGroup 表示一個(gè)表單，F(xiàn)ormControl 表示表單中的字段。因此，F(xiàn)ormControl 必須包裹在 FromGroup 下面。

下面，我們先簡單的構(gòu)建一個(gè)響應(yīng)式表單。

別忘記導(dǎo)入 ReactiveFormsModule 模塊。

@Component({ selector: 'app-validation', template: ` <form [formGroup]="form" (ngSubmit)="_submitForm(form)"> <input type="email" formControlName="email"> <input type="text" formControlName="nickname"> <button type="submit" [disabled]="form.invalid">Submit</button> </form> `})export class UserEditComponent { constructor(private fb: FormBuilder, private route: ActivatedRoute) {}  ngOnInit() { this.form = this.fb.group({  email: ['', Validators.compose([Validators.required, Validators.email])],  nickname: ['', [Validators.required]] });  this.route.params  .switchMap((params: Params) => loadUser(+params['id']))  .subscribe(data => {  // Updating value  }); }  loadUser() { return Observable.of({ email: 'xx@xx.com', nickname: 'cipchk' }).delay(1000); }  _submitForm({ value }) { // Save value }}

以上的這些代碼再熟悉不過了。假設(shè) UserEditComponent 是由路由 /user/edit/1 觸發(fā)，那么會發(fā)生幾個(gè)幾件事情。

首先，創(chuàng)建一個(gè)空的響應(yīng)式表單 form。

this.form = this.fb.group({ email: ['', Validators.compose([Validators.required, Validators.email])], nickname: ['', [Validators.required]]});

表單的內(nèi)容有 email、nickname 兩個(gè)字段。

然而，HTML中，除了 formGroup、formControlName 的配置以外，也看不到任何有關(guān)對表單的校驗(yàn)代碼。但，當(dāng)我們輸入一個(gè)無效 Email 時(shí) input 會自動加上 ng-invalid 類。

這便是響應(yīng)式表單的魅力。

現(xiàn)在我們回到正題，將分別針對 setValue、patchValue、reset 三種不同更新表單值實(shí)際上會發(fā)生什么。