前言

本周的一個(gè)需求是在一個(gè)異步驗(yàn)證上加上防抖，防抖，以前也接觸過，依稀記得不難，就沒再去看angluar的官方文檔，直接就開始google寫了，然后……一不小心就掉坑里了。

突然沒了效果的驗(yàn)證功能

在網(wǎng)上一番查詢以后，選了一個(gè)最簡單，最符合的實(shí)現(xiàn)

一番修改以后我的代碼成了下面這樣

 public oldPasswordValidator(): AsyncValidatorFn {
  return (ctrl: AbstractControl): Promise<ValidationErrors | null> | Observable<ValidationErrors | null> => {
  rerutn ctrl.valueChanges.pipe(
    debounceTime(2000),
    distinctUntilChanged(),
    switchMap(value => this.checkPasswordIsRight(value)),
    map((isRight: boolean) => (isRight ? null : {passwordError: true})),
    catchError(() => null));
  };

但是驗(yàn)證器并沒有效果，在c層獲取到的始終是null，而在方法中打印結(jié)果，卻可以發(fā)現(xiàn)，能夠產(chǎn)生正確的結(jié)果

但是獲取到的相關(guān)錯(cuò)誤一直是沒有,更讓我感到驚訝的是表單的valid和invalid竟然同時(shí)處在了false,他們不是應(yīng)該互斥嗎？不是反義詞嗎？

FormControl的status

首先還是解決valid與invalid的疑惑吧,查詢官方文檔。

FormControl的status繼承自AbstractControl

AbstractControl是 FormControl、FormGroup 和 FormArray 的基類。它提供了一些所有控件和控件組共有的行為，比如運(yùn)行驗(yàn)證器、計(jì)算狀態(tài)和重置狀態(tài)。 它還定義了一些所有子類共享的屬性，如 value、valid 和 dirty。不允許直接實(shí)例化它。

找到valid

至此，這個(gè)疑問解決了，互斥的并不僅僅是valid和invalid,

還有一個(gè)檢查進(jìn)行狀態(tài)：pending和禁止disable,驗(yàn)證一下，果然此時(shí)的狀態(tài)是在pending

為何會(huì)一直在pending狀態(tài)？

接著查看表單驗(yàn)證的官方文檔

自定義異步驗(yàn)證器和同步驗(yàn)證器很像，只是它們必須返回一個(gè)稍后會(huì)輸出 null 或“驗(yàn)證錯(cuò)誤對象”的承諾（Promise）或可觀察對象，如果是可觀察對象，那么它必須在某個(gè)時(shí)間點(diǎn)被完成（complete），那時(shí)候這個(gè)表單就會(huì)使用它輸出的最后一個(gè)值作為驗(yàn)證結(jié)果。（譯注：HTTP 服務(wù)是自動(dòng)完成的，但是某些自定義的可觀察對象可能需要手動(dòng)調(diào)用 complete 方法)
返回的可觀察對象必須是有限的，也就是說，它必須在某個(gè)時(shí)間點(diǎn)結(jié)束（complete）。要把無盡的可觀察對象轉(zhuǎn)換成有限的，可以使用 first、last、take 或 takeUntil 等過濾型管道對其進(jìn)行處理。

結(jié)果很明顯了，上面的觀察者對象是通過valueChangs產(chǎn)生的, 被人訂閱后，并不會(huì)主動(dòng)的調(diào)用complete()方法，而會(huì)不停的發(fā)布新值。下面的例子可以看出來

給他加個(gè)first()讓他只返回第一個(gè)結(jié)果,果然好使了：

first(predicate: function(value: T, index: number, source: Observable<T>): boolean, resultSelector:function(value: T, index: number): R, defaultValue: R): Observable<T | R>
只發(fā)出由源 Observable 所發(fā)出的值中第一個(gè)(或第一個(gè)滿足條件的值)。

如果你足夠細(xì)心

看的太不仔細(xì)了，到解決這個(gè)問題之前，一直都沒發(fā)現(xiàn)……

一個(gè)更簡單的實(shí)現(xiàn)方式

驗(yàn)證的防抖功能實(shí)際上并不需要通過上面的方式實(shí)現(xiàn)，盡管上面也并不困難。

最簡單的防抖方式，在官方文檔已經(jīng)提供了:

默認(rèn)情況下，每當(dāng)表單值變化之后，都會(huì)執(zhí)行所有驗(yàn)證器。對于同步驗(yàn)證器，沒有什么會(huì)顯著影響應(yīng)用性能的地方。不過，異步驗(yàn)證器通常會(huì)執(zhí)行某種 HTTP 請求來對控件進(jìn)行驗(yàn)證。如果在每次按鍵之后都發(fā)出 HTTP 請求會(huì)給后端 API 帶來沉重的負(fù)擔(dān)，應(yīng)該盡量避免。

我們可以把updateOn屬性從change（默認(rèn)值）改成submit或blur來推遲表單驗(yàn)證的更新時(shí)機(jī)。

 /**
  * 初始化表單
  */
 initForm() {
  this.modifyPasswordForm = this.fb.group({
    oldPassword: [null, [Validators.required], [this.userService.oldPasswordValidator()]],
    newPassword: [null, Validators.required],
    confirmNewPassword: [null, Validators.required]

    // updateOn 作用是在什么時(shí)候更新表單數(shù)據(jù)
    // https://angular.cn/guide/form-validation#note-on-performance
   }, {updateOn: 'blur'},
  );
 }

想了解更多updateOn的內(nèi)容，可查看這篇文章。

總結(jié)

這次的問題可以完全說出在了看文檔不仔細(xì)，神奇的是看了幾遍那個(gè)StackOverflow上的回答都沒發(fā)現(xiàn)他比我多了一個(gè)first(),雖然因此浪費(fèi)了不少的時(shí)間，但收獲也是巨大的，這波不虧。

好了，以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對腳本之家的支持。