Angular: FormControl.setValidators ... getValidatorsがないのはなぜですか？

@Icepick返すものは何もありません。 バリデーターは、配列ではなく単一のオブジェクトとして格納されます。

@DzmitryShylovichこれは実装できないという意味ですか？ 個人的には、メタデータが添付されたバリデーターの読み取り専用コピーのみが必要です。

検証メッセージのオブジェクトが渡されるディレクティブを作成しています。これは、検証ルール名がキーで、値が表示されるメッセージであるオブジェクトです。 このオブジェクトとNgControlのセットバリデーターを比較して、特定のメッセージが欠落している場合にユーザーに警告するようにします。

@Bidthedogと同様の理由でこれも見たいです。 たとえば、 Validator.requriedがコントロール上にある場合、これをプログラムでフォームに示します。 必要なのは読み取り専用です。 現在私ができる最善のことは、コンポーネントに配列を定義し、それをフォームコントロール定義に渡すことです。 それはかなりすぐに醜くなるでしょう！

これはロードマップにありますか？ある場合、この機能にETAはありますか？

その通り。 私のフォームサービスには、基本的に3つの大きな厄介な重複定義があります。 以下のコードスニペットは、私がまとめているかなり大きな6ページのフォームからの小さな抜粋です。 これは、1ページ目（詳細）と2ページ目（医療）の始まりです。

作成/定義するには：

  private createForm() {
    this.form = this.fb.group({
      details: this.fb.group({
        NHSNumber: [null, [Validators.required, Validators.pattern(/^\d{3}-\d{3}-\d{4}$/)]],
        titleId: [null, [Validators.required]],
        firstName: [null, [Validators.required, Validators.maxLength(10)]],
        middleNames: null,
        lastName: [null, [Validators.required]],
        DOB: [null, [Validators.required]],
        genderId: [null, [Validators.required]],
        regionId: [null, [Validators.required]],
        maritalStatusId: [null, [Validators.required]],
        occupationTypeId: [null],
        occupationId: null,
        telephoneNo: null,
        mobileNo: null,
        houseNumber: null,
        streetName: null,
        town: null,
        city: null,
        county: null,
        postcode: null,
        GPId: null,
        nextOfKinId: null,
        livesWith: null
        //vehicleLicenseTypeId?: number[]
      }),
      medical: this.fb.group({
        gpId: [null, [Validators.required]]
      })
    });
  }

移入するには：

  private populateForm() {
    let m = this.model;
    this.form.setValue({
      details: {
        NHSNumber: this.getTextValue(m.NHSNumber),
        titleId: this.getLookupValue(m.titleId),
        firstName: this.getTextValue(m.firstName),
        middleNames: this.getTextValue(m.middleNames),
        lastName: this.getTextValue(m.lastName),
        DOB: this.getDateValue(m.DOB),
        genderId: this.getLookupValue(m.genderId),
        regionId: this.getLookupValue(m.regionId),
        maritalStatusId: this.getLookupValue(m.maritalStatusId),
        occupationTypeId: this.getLookupValue(m.occupationTypeId),
        occupationId: this.getLookupValue(m.occupationId),
        telephoneNo: this.getTextValue(m.telephoneNo),
        mobileNo: this.getTextValue(m.mobileNo),
        houseNumber: this.getTextValue(m.houseNumber),
        streetName: this.getTextValue(m.streetName),
        town: this.getTextValue(m.town),
        city: this.getTextValue(m.city),
        county: this.getTextValue(m.county),
        postcode: this.getTextValue(m.postcode),
        GPId: this.getLookupValue(m.GPId),
        nextOfKinId: this.getLookupValue(m.nextOfKinId),
        livesWith: this.getTextValue(m.livesWith)
      },
      medical: {
        gpId: this.getLookupValue(m.GPId) || 1
      }
    });

検証ルール。 完全ではありませんが、これがどのように乱雑になり、速くなるかがわかります

  private formValidationMessages = {
    details: {
      NHSNumber: {
        required: '\'NHS Number\' is required',
        pattern: '\'NHS Number\' must be in the format \'NNN-NNN-NNNN\' where N is a digit'
      },
      titleId: {
        required: '\'Title\' is required'
      },
      firstName: {
        required: '\'First Name\' is required'
      }
    },
    medical: {
    }
  };

私は1つのオブジェクトセットですべてのフォームルールを定義する作業を開始しました。これは、上記の関数を繰り返し処理/投影することを考えています（まだそれほど進んでいませんが）。

  private formValidationMessages = {
    details: {
      NHSNumber: {
        required: '\'NHS Number\' is required',
        pattern: '\'NHS Number\' must be in the format \'NNN-NNN-NNNN\' where N is a digit'
      },
      titleId: {
        required: '\'Title\' is required'
      },
      firstName: {
        required: '\'First Name\' is required'
      }
    },
    medical: {
    }
  };

もちろん、これに加えて、データモデルの定義があり、次にバックエンドのすべてのレイヤーがあります。 コードの膨張を減らすために私たちにできることがあるはずですか？

また、FormControl用に構成されたバリデーターを取得できないことにも見舞われました。

FormBuilderに渡される前に構成オブジェクトをラップし、コントロール名と指定されたバリデーターの間のマッピングを追跡するユーティリティサービスを追加することで、この問題を回避しました。

この追加サービスの必要性を取り除くことは当然素晴らしいことです😄

ここに投稿してから、すべてのフォーム構成を1つの大きなオブジェクトに統合し、構成に基づいてフォームとモデル間のマッピングを行ういくつかのヘルパーメソッドを作成しました。 それはすべてあまりにも複雑に思えますが、それは私が持っていた学習曲線である可能性があります。

こんにちは、
この機能について何か言葉があるかどうか疑問に思っています。 特定のアイテムを必要に応じて視覚的にマークできることは、最新のフォームUIに期待される基本的な機能のように思えます。 ただし、フィールドが必須かどうかに関係なく情報を取得する方法がないため、リアクティブフォームを使用してこの機能を実装することはできません。

それは不可能ではありません、それはただたくさんの仕事です。

@Bidthegodは、この機能をAngularで実装するのは大変な作業になるのでしょうか、それともAngularコンポーネントでバリデーターを取得するのは大変な作業になるのでしょうか。

コンポーネント内のバリデーターを取得できる場合は、その方法に関する入力を歓迎します。

または、特定のコンポーネントタイプ（入力、選択）の方が簡単な場合は、それも役立ちます。

@Toub私がやったことは、すべての個々のフォームフィールドとそのすべての設定（表示、バリデーター、ルールなど）を含む「config」オブジェクト構造を構築することでした。 次に、FormGroupを構築する構成を照会するためのいくつかのヘルパーメソッドを作成しました。 各フォームにはフォームサービスがあり、基本コンポーネントから継承します。

簡単な修正とは言えませんし、大量のコードもありますが、かなりエレガントで、かなり複雑なフォームを簡単に作成できるようになりました。 あなたが見るために要点でコードのいくつかを投げました、しかし私は今のところそれを適切にモジュール化する時間がありません。 私が書いたすべてのカスタムフォーム入力コンポーネントを含め、これにはかなりの数のファイルがありません。

https://gist.github.com/Bidthedog/1dc7d10cda1759061c09f44f7b48cbf3

@Bidthedogそれは私のニーズに応えませんが、要点は他の人にも役立つので、あなたの答えに感謝します。

やあみんな、私はバリデーターを返すための簡単なヘルパーを作成しました（必要なだけですが、他の人のために拡張することができます）：

getValidators(_f) {
  return Object.keys(_f).reduce((a, b) => {
    const v = _f[b][1];
    if (v && (v === Validators.required || v.indexOf(Validators.required) > -1)) {
      if (!a[b]) { a[b] = {}; }
      a[b]['required'] = true;
    }
    return a;
  }, {});
}

const _f = {
  id: [],
  name: [null, Validators.required],
  phone: [],
  email: [null, [Validators.required, Validators.email]]
};
this.frmMain = this._fb.group(_f);
console.log(this.getValidators(_f));    // {name: {"required": true}, email: {"required": true}}

私のニーズに合います👍

私は同意します。現在のコントロールのメソッドで取得できるバリデーターの読み取り専用リストがあると非常に役立ちます。

この機能の+1

読み取り専用リストの場合は+1

+1

すでに存在するバリデーターを失うことなく動的にバリデーターを追加するには、その機能が必要です。 何かのようなもの：
Object.keys(this.myForm.controls).forEach(key => { if (map.get(key)) { this.myForm.get(key).setValidators(this.myForm.get(key).getValidators().push(Validators.required)) } });
完全に説明されている： https ：//stackoverflow.com/questions/46852063/how-to-dynamically-add-validators-to-the-forms-in-angular-2-4-using-formbuilde。
これは一般的なものでなければなりません

実際、composeValidators（https://github.com/angular/angular/blob/master/packages/forms/src/directives/shared.ts#L139）を使用してバリデーターを動的に追加することはそれほど難しくありません。 バリデーターの削除がより大きな問題だと思います。 ブール値でそれを行うことができますが、バリデーターはもはや純粋関数ではありません。

この関数は、FormGroupsおよびFormControlsで機能して、必要なバリデーターを決定する必要があります

      export const hasRequiredField = (abstractControl: AbstractControl): boolean => {
        if (abstractControl.validator) {
            const validator = abstractControl.validator({}as AbstractControl);
            if (validator && validator.required) {
                return true;
            }
        }
        if (abstractControl['controls']) {
            for (const controlName in abstractControl['controls']) {
                if (abstractControl['controls'][controlName]) {
                    if (hasRequiredField(abstractControl['controls'][controlName])) {
                        return true;
                    }
                }
            }
        }
        return false;
    };

@mtinnerそれは本当に素晴らしい発見でした。 それは私に初期セットを取得しています。 オブザーバブルのバリデーターを返すことができるように、APIに追加する価値はまだあると思います。 そうすれば、条件付きの必須コントロールを見つけるのは非常に簡単です。 ここで提案されている回避策を適用して、これらのインスタンスをキャッチできるかどうかはわかりません。

Angular Connect 2017の非常に素晴らしいプレゼンテーションで、 @ karaは「カスタムフォームコントロールは素晴らしく、怖くない」と言って終了します。 良いですが、カスタムコントロールのこの重要な機能がありません

+1

PRの時間はありませんが、これが私が思いついたものです：

import {FormControl} from '@angular/forms';
import {AsyncValidatorFn, ValidatorFn} from '@angular/forms/src/directives/validators';
import {Observable} from 'rxjs/Observable';
import {Subject} from 'rxjs/Subject';
import {AbstractControlOptions} from '@angular/forms/src/model';

export class DescendingFormControl extends FormControl {

    private asyncValidationChangesSubject = new Subject<AsyncValidatorFn | AsyncValidatorFn[]>();
    private validationChangesSubject = new Subject<ValidatorFn | ValidatorFn[] | null>();

    public readonly validationChanges: Observable<ValidatorFn | ValidatorFn[] | null>;
    public readonly asyncValidationChanges: Observable<AsyncValidatorFn | AsyncValidatorFn[]>;

    constructor(formState?: any, validatorOrOpts?: ValidatorFn | ValidatorFn[] | AbstractControlOptions | null, asyncValidator?: AsyncValidatorFn | AsyncValidatorFn[] | null) {
        super(formState, validatorOrOpts, asyncValidator);
        this.validationChanges = this.validationChangesSubject.asObservable();
        this.asyncValidationChanges = this.asyncValidationChangesSubject.asObservable();
    }

    public setValidators(newValidator: ValidatorFn | ValidatorFn[] | null): void {
        super.setValidators(newValidator);
        this.validationChangesSubject.next(newValidator);
    }

    public setAsyncValidators(newValidator: AsyncValidatorFn | AsyncValidatorFn[]): void {
        super.setAsyncValidators(newValidator);
        this.asyncValidationChangesSubject.next(newValidator);
    }
}

私が自由な時間を得る前に誰かがPRの仕事全体をやろうとしているなら、それのために行ってください！

+1

+1

+1

問題：閉じ込められている

現在のバリデーターの配列は存在しますが、私たちには利用できません...
バリデーターの静的メソッドcomposeを見てください。これは、フォームコントロールでバリデーターの配列を定義するときに舞台裏で使用されるメソッドです。

 static compose(validators: (ValidatorFn|null|undefined)[]|null): ValidatorFn|null {
    if (!validators) return null;

    // Here it is
    const presentValidators: ValidatorFn[] = validators.filter(isPresent) as any; 

    if (presentValidators.length == 0) return null;

    return function(control: AbstractControl) {
      return _mergeErrors(_executeValidators(control, presentValidators));
    };
  }

https://github.com/angular/angular/blob/master/packages/forms/src/validators.ts#L342

ご覧のとおり、 presentValidatorsは私たちが探しているものですが、クロージャに_トラップ_されているためアクセスできず、 composeから取得した値のみが、トリガーされたすべてのエラーを含むオブジェクトです。与えられた値。

したがって、バリデーターを推測する唯一の方法は、フォームコントロールでエラーを手動でトリガーすることです。これにより、バリデーターの名前が参照されます。

ハック：別のコントロールでエラーをトリガーする

バインドされたフォームコントロールでエラーをトリガーしたくない。 代わりに、テンプレートへのバインドがない新しいフォームコントロールを作成し、同じValidator関数を適用してから、値を設定して必要なエラーをトリガーする必要があります。

// Your form control, actually binded to a form in your template

emailControl = new FormControl('', [Validators.required, Validators.email])

// Elsewhere in your code
// You use dummy form controls, on which you apply your original form control validators and various values, to trigger the errors.

const errorsWhenEmpty = new FormControl('', this.emailControl.validator, this.emailControl.asyncValidator).errors
const errorsWhenOneChar = new FormControl('x', this.emailControl.validator, this.emailControl.asyncValidator).errors

// Or you can simply reuse the first dummy control with `setValue()`

理想からはほど遠いですが、バリデーター自体を手に入れることができるまでは、私が見つけた中で最も汚い方法ではありません。

FormControlクラスから拡張し、子クラスのフィールドに、コンストラクターに渡されたValidator関数のコピーを保存することをお勧めします。次のようになります。

export class ExtFormControl extends FormControl {
  private _syncValidators: ValidatorFn | ValidatorFn[];

  private _asyncValidators: AsyncValidatorFn | AsyncValidatorFn[];

  constructor(formState?: any, validatorOrOpts?: ValidatorFn | ValidatorFn[] | null,
              asyncValidators?: AsyncValidatorFn | AsyncValidatorFn[] | null) {
    super(formState, validatorOrOpts, asyncValidators);
    this._syncValidators = validatorOrOpts;
    this._asyncValidators = asyncValidators;
  }


  getSyncValidators(): ValidatorFn[] {
    if (typeof this._syncValidators === 'function') {
      return [this._syncValidators];
    } else {
      return this._syncValidators;
    }
  }

  getAsyncValidators(): AsyncValidatorFn[] {
    if (typeof this._asyncValidators === 'function') {
      return [this._asyncValidators];
    } else {
      return this._asyncValidators;
    }
  }

  setValidators(newValidator: ValidatorFn | ValidatorFn[] | null): void {
    super.setValidators(newValidator);
    this._syncValidators = newValidator;
  }

  setAsyncValidators(newValidator: AsyncValidatorFn | AsyncValidatorFn[] | null): void {
    super.setAsyncValidators(newValidator);
    this._asyncValidators = newValidator;
  }

}

私はすべて、バリデーターの読み取り専用リストを求めています。 ReactiveFormsを使用して、テンプレートではなくFormBuilderコードを介してmaxLengthなどの制約を構成することが期待される場合があります。 ただし、現在、いくつかの動作（フォーカスを次のフィールドに移動する、クレジットカード入力の一般的なケースなど）を定義したり、必要に応じてラベルを自動的にマークしたりするために、HTMLにmaxlengthを配置する必要があります。

フォームに入力されると更新されるバリデーターをプログラムで設定する必要があります。FormControlでバリデーターを読み取れると非常に便利です。 私は@moniuchに同意します。ReactiveFormsを使用すると、これが可能になると期待されます。 それが実装されることを願っています。

更新はありますか？

うーん、 1985年にこの化合物が興味深い問題だと思っています1
セットされたバリデーターを確認したり、優先順位を付けたりすることはできません。 :(

コントロールの「validator」プロパティを確認して解決しました。 それはACTIVEバリデーターでオブジェクトを返します。 バリデーターが設定されていて、バリデーターが真で​​あるための条件が満たされている場合。
私の例では、ネストされたコンポーネントで使用されるリアクティブフォームですらあります。

親コンポーネント

PARENTコンポーネントのReactiveFormGroupのバリデーター

return this.formBuilder.group({
      username: ['', [Validators.required, Validators.min(3), Validators.email]],
     ...
});

名前はテストのみを目的としています

<app-input name="txtfield" 
[parentForm]="loginForm" parentFormControlName="txtfield" 
></app-input>

ネストされたコンポーネント

 <div [formGroup]="parentForm" class="form-control-group">
   ...
        <input #inputField  name="{{parentFormControlName}}" 
            formControlName="{{parentFormControlName}}" 
            matInput 
            placeholder="{{placeholderTxt}}"
        >
  ...
    </div>

ネストされたコンポーネントでは、「必須」のバリデーターのみが必要なため、AfterViewIinitの後に一度だけチェックします。

ngAfterViewInit() {
    // Lookup if this field is required or not
    if (this.parentForm.controls[this.parentFormControlName].validator != null) {
    // MAYBE CHECK FOR required field in returned OBJECT!!
      console.log('Validators of ' + this.parentFormControlName + ' = ', 
           JSON.stringify(
             this.parentForm.controls[this.parentFormControlName]
                      .validator(this.parentForm.controls['username']);)
            );

    } else {
      console.log('No validator set for component ' + this.parentFormControlName); 
    }

デバッガーが停止している間のブラウザーコンソールでの出力：

[DEBUG] STATUS of username =  {"required":true}
>this.parentForm.controls[this.parentFormControlName].validator(this.parentForm.controls[this.parentFormControlName])
{required: true}
required: true
__proto__: Object

それ以外の場合-バリデーターが設定されていない場合-「null」と表示されます！

その他の状況

入力テキストフィールドにデフォルト値がある場合

input-text-fieldにデフォルト値がある場合、これは必須値がtrueであることを示しませんが、フィールドが必須であり、入力されていない場合にのみ、フィールド（=太字の行）を強調表示します。

必要な値以外

「DoCheck」または「OnChanges」を使用して変更を監視し、必要に応じて「email」または「min」バリデーターを取得する場合は、他のバリデーターステータスをいつでも確認できます。

@Angularチーム、現在のバリデーターリストをチェックし、実行時に特定のバリデーターを削除するAPIが本当に必要です。 これは多くの問題を解決します。

なぜ「control.errors」と「controls.validators」がpreatymutchを同じことをしているのですか？
「 .errors 」は、エラー状態に達するよりもすべてのエラーを表示する必要があります。
「 .validators 」は、このコントロールのために、登録されているすべてのバリデーターを返す必要があります。
それと同じくらい簡単ですか？

この機能も見たいです。 しかし！ 私が見ている大きな問題の1つは、バリデーターが（通常は）純粋関数であるということです。つまり、バリデーターは深くネストすることもできます。

私たちのプロジェクトには、他のバリデーター（など）から構築されたドメイン関連のバリデーターがたくさんあります。 たとえば、私たちのIBANバリデーターは、 exactLength 、 pattern 、および内部でIBANチェックディジットバリデーターを使用します。 このパターンに従うと、より具体的な検証エラーが発生し、問題をより詳細に説明するエラーメッセージを使用できるようになります（ユーザビリティにとってはより良い）。

したがって、すべてのバリデーターを取得するための新しい方法を検討する場合、質問は次のとおりです。「上位のバリデーター」のみが返されますか？ さらに、それらのバリデーターの名前は何ですか？ 全体として、現在の検証の実装では、簡単な解決策はないように思われます...

TL; DR：Angularフォームモジュールの多くのものを変更し、既存のコードを壊さずにそれは不可能です。

皆さん、関連するソースコードは次のとおりです。
packages / forms / src / model.ts
packages / forms / src / validators.ts
そして多分packages / forms / src / directives / validators.ts

次の問題が見つかりました。

• まず第一に、バリデーターはそれを識別する方法のない単なる愚かな関数オブジェクトです。 関数の配列を取得できたとしても、それではどうしますか？ 正規表現バリデーターが単なる関数である場合、どのようにして正規表現バリデーターを削除できますか？ これが正規表現バリデーターであることを識別する方法が必要です。これらを追加または個別に削除する場合は、これが必須のバリデーターです。 したがって、 addValidator関数を実装することはできますが、 removeValidator関数を実装することはできません。
• 次に、 setValidatorsを実行すると、compose関数が最終的に呼び出されます。 すべてのバリデーター関数を1つの関数にまとめ、内部の_executeValidators関数を呼び出して実際に呼び出します。 したがって、最終的には元のバリデーターの配列がなく、すべてのエラーのリストがマージされた巨大なメガバリデーターしかありません。

そのことから、バリデーターの概念にいくつかの重大な変更を導入せずにgetValidatorsまたはremoveValidatorを実装することは不可能であると結論付けました。 addValidatorsを実装することは可能のようですが、バリデーターを追加することしかできず、既存のバリデーターを削除できない場合、誰がそれを必要としますか？

では、アプリに条件付きの動的検証を実装する場合、たとえば、既存のすべてのメールバリデーターを失うことなくこのチェックボックスが設定されている場合にこのメールフィールドを必須にする場合は、どうすればよいでしょうか。 私は2つのアプローチを見つけました：

• フィールドのデフォルトのバリデーターを変数のどこかに保存できます。 メールを必須にするときは、 setValidator関数を使用して、Validator.required +すべてのデフォルトのバリデーターを渡します。
• フォームコントロールに必要なバリデーターを使用する代わりに、チェックボックスとフィールドの変更の両方を監視するフォームグループバリデーターを作成できます。 チェックボックスがtrueに設定されている場合、電子メールフィールドが必須であるかのように動作します。

@ ganqqwerty …正解です。 これが、 addValidator(...)またはremoveValidator(...)が存在しない理由です。 識別はありません。 バリデーター自体は、どのコントロールが実行されているかを知りません。

@ganqqwertyこれを実装するのが簡単だと言っているわけではありませんが、ここではあなたの推論が有効ではないと思います。

正規表現バリデーターをどのように削除できますか

バリデーターへの参照を渡すことによって。 イベントリスナーを削除するのと同じ方法です。

したがって、最終的には元のバリデーターの配列がありません

これは単なる内部設計の決定であり、現在、パブリックAPIのどこにも公開されていません。 関数を何度も作成するのではなく、元の配列を保持することを選択すると、バリデーターの配列をクロージャーに保持する必要がある追加の関数がないため、実際にはパフォーマンス上の利点があります。

既存のすべての電子メールバリデーターを失うことなくこのチェックボックスが設定されている場合にこの電子メールフィールドを必須にするには：[...]フォーム制御必須バリデーターを使用する代わりに、チェックボックスとフィールドの変更の両方を監視するフォームグループバリデーターを作成できます。

これは意図された動作ではありませんか？ 電子メールフィールドを使用したフォームコントロールは、有効な電子メールアドレスがあればそれ自体で有効です。 チェックボックスの値がtrueの場合、電子メールが存在する場合、_group_は有効です。 これはバリデーターの回避策ではありませんが、フォームの正しいレベルでの適切な使用法です。

これを明確にしてくれてありがとう！ そのような機能の実装をスケジュールできるということですか？

バリデーターへの参照を渡すことによって。

したがって、バリデーターへの参照を保持すると、それを削除することが可能になります。 バリデーターとして無名関数を提供するだけでは、それを削除することはできません。 うーん、確かにそれはremoveEventListenerのように見えます

この機能がないと、特定のコントロールから特定のバリデーターを削除することはできません。

これは私が今必要としているものであり、私はこれを解決することはできません。 非常に基本的なものがAngularでは不可能な場合があります。

this.myAbstractFormControl.removeValidatorAndKeepTheRestAsIs(Validators.required)

@andreElricoバリデーターを削除するためのユースケースは何ですか？ これについて考えれば考えるほど、フォームのバリデーターを変更することの意味がわかりにくくなります。 フォームの別のフィールドに基づいてバリデーターを動的に変更する必要がある場合、バリデーターの配置は間違っています。必要なのは、フォームコントロールバリデーターではなく、フォームグループバリデーターです。

たとえば、2つのシナリオで動的に入力を介して提供されるのと同じformGroupを使用しようとしています。 1つは各フィールドで必要なものであり、2つ目は必要なIFが存在するものを削除し、atLeastOneFieldバリデーターをformGroupに適用する場合です。

これが私のstackblitzImが取り組んでいるところです。

既存の検証処理に関してAngularチームが生み出した設計上の欠陥を保護するものがある理由がわかりません。
AngularForm-検証はCRUDである必要があります。

@andreElrico私が言ったように、フォームに相互に依存する検証を持つ2つの入力がある場合、バリデーターはフォームコントロールではなくフォームグループにある必要があります。

たとえば、2つのパスワードフィールドがある場合、最初のコントロールが変更されるたびに2番目のコントロールのバリデーターを変更しないでください。 代わりに、バリデーターは2つのパスワードフィールドを含むグループに移動する必要があります。 各パスワードフィールドには、パスワードが8文字以上である必要があるという検証がありますが、グループには、同じである必要があるというバリデーターがあります。 それ自体では、各パスワードフィールドは他のパスワードフィールドの存在を認識していません。 グループはそれらを一緒に保持します。

あなたがのようなものを持っているなら

( ) a
( ) b
( ) other [ _____ ]

ここで、ユーザーが「その他」を選択した場合、その横に入力フィールドが必要です。この場合も、入力フィールドで「必須」のバリデーターを切り替えないでください。 代わりに、フォームグループ全体を検証する必要があります。ラジオボタンコントロールは「a」、「b」、または「other」のいずれかである必要があり、「other」の場合は入力フィールドが存在する必要があります。

ラジオボタンにリスナーを配置してから、ラジオボタンの値に基づいて入力フィールドの「必須」バリデーターを切り替える必要はありません。

検証にCRUDAPIが必要だとあなたが信じている理由がわかりません。 私は何も擁護していません、私は合理的で議論を持って話しているのです。 バリデーターを取得、削除、切り替えするためのメソッドを実装すべきではないと言っているのではありません。ここにいるほとんどの人が、実際にはアンチパターンであるCRUD検証のユースケースを持っていると言っています。 コントロールはスタンドアロンユニットであり、存続期間中は検証ルールを変更しません。 コントロールが依存している場合、それらはグループに入れられ、グループが検証されます。

コメントと時間をありがとう@lazarljubenovic 。
あなたは私のstackblitzをよく見ていないように感じます。 1つのシナリオのformGroupに「ラッピング」ロジックを適用しています。 フォームには、バリデーターを動的に変更する必要がある2つの異なるシナリオがあります。 そして、formGroupを扱うその「段階」では、バリデーターはすでに「構成」されているので、CRUDはありません：D。

私はこの問題を回避することができ、これがいつか修正されることを願っています。
167👍はこの機能に対する高い要望を反映しているようです。

時間があれば、もっと知りたいです。

「コントロールはスタンドアロンユニットであり、存続期間中は検証ルールを変更しません。」

それに関するリソースはありますか？

「コントロールが依存している場合、それらはグループに入れられ、グループが検証されます。」

これは、実際には限界もあります。

• https://github.com/angular/angular/issues/31105

また、この問題とは関係ありません。
グループがコントロールの検証を引き継ぐ場合、エラーはグループに設定されるため、コントロールに視覚的に反映されません。 したがって、子コントロールに対して手動でエラーを設定および削除する必要があります。 （それは*の大きな苦痛です）。

良い週末をお過ごしください。

私は確かに@lazarljubenovicの見方を理解しています。

ただし、私は、複雑な構成を必要とする非常に動的なマルチパートのエンタープライズフォームに取り組んでいます...多くの非表示/表示、検証要件の依存関係チェーンなど。

この複雑さを処理する方法は、依存関係のトリガーを担当するフォームコントロール、グループ、または配列でvalueChangesをサブスクライブし、シナリオごとにsetValidatorsまたはclearValidatorsを使用することです。 特定のバリデーターをターゲットにする方法がないため、いつでも適用される可能性のある検証ルールの各セットを保存し、それらを再適用します。 すべてのバリデーターを取得したり、個々のバリデーターを追加したり、特定のバリデーターを削除の対象にしたりできると便利です。これは、すべて不変性を念頭に置いて設計できるようです。

「コントロールはスタンドアロンユニットであり、存続期間中は検証ルールを変更しません。」

それに関するリソースはありますか？

いいえ; それは本当にフォームのデザインの私の解釈です。

グループがコントロールの検証を引き継ぐ場合、エラーはグループに設定されるため、コントロールに視覚的に反映されません。

正直なところ、これらのエラーが発生するはずのUIの観点からも疑わしいです。 2つのフィールドが一緒に再生されないが、フォームが大きく離れている場合、エラーをどこに書き込む必要がありますか？ 最初に一歩下がってフォームのUXを修正する必要があるように私には思えます。

もちろん、フォームは野獣であり、すべてのユースケースに適合するわけではありません。 _本当に_クレイジーなコントロールを備えた非常に複雑なフォームがある場合、 @angular/formsはまったく使用しません。 @angular/formsは、ユースケースの95％をカバーし、多くの労力をかけずにフォームをすばやく作成できる優れたユーティリティだと思います。

Array#map 、 Array#filter 、 Array#reduceを使用するのが好きなのと同じように、インデックス変数を使用した古き良きforループが、より複雑な反復の最良のソリューションである場合があります。 。

これらのメソッドを追加するのではないことをもう一度明確にしておきたいと思います。 _大多数の人がそれらを悪用するような気がします。 多分それはフットガンでしょう。 繰り返しになりますが、誰かがそれを誤用する可能性があるという理由だけで、有用なものをフレームワークに追加すべきではないと思います。 トイレの水で歯を磨くこともできます。そのため、トイレは禁止されていません。

非常に複雑なフォームで非常にクレイジーなコントロールを使用している場合は、@ angle / formsをまったく使用しません。 @ angle / formsは、ユースケースの95％をカバーし、多くの労力をかけずにフォームをすばやく作成できる優れたユーティリティだと思います。

これはAngularFormsの公式の市場ポジショニングですか？ 巨大なプロジェクトに役立つ万能ツールとして考えました。

非常に複雑なフォームで非常にクレイジーなコントロールを使用している場合は、@ angle / formsをまったく使用しません。 @ angle / formsは、ユースケースの95％をカバーし、多くの労力をかけずにフォームをすばやく作成できる優れたユーティリティだと思います。

これはAngularFormsの公式の市場ポジショニングですか？ 巨大なプロジェクトに役立つ万能ツールとして考えました。

「リアクティブフォーム」は、検証を完全に制御できるなど、複雑で高度にカスタマイズされたユースケースを対象としています;）

あなたはそれを完全に制御することができます。 検証する対象（グループまたはコントロール）を適切に判別する必要があります。

これは何か牽引力になりましたか？ すべてを切り離しておくために、入力としてformGroupのみを使用してバリデーターを動的に変更したいと思います!!! リアクティブフォームは素晴らしいですが、これは私の唯一の持ちこたえです。

Soooooooooバリデーターを動的に追加するコードをユニットテストするにはどうすればよいですか？

バリデーターを適用したコントロールを_読み取る_ことができないため、明らかな単体テストは機能しないようです。

_これは機能しません_
expect(component.formControl.validators.length).toEqual(2);

更新：
実際、あなたはそれをこのように行うことができます。 ただし、バリデーターを読み取る方が明らかに安価です。

component.myCtrl.setValue('');
expect(component.myCtrl.errors.required).toBeTrue();

私はリアクティブフォームの大ファンであり、それらを使って何ができるかが大好きですが、FormControlにバリデーターについて尋ねることができないなどの小さなことは見落としのようです。 FormControlには非常に多くの状態プロパティがあるとすると、少なくとも.requiredプロパティを使用可能にすることを妨げるものは何ですか？ これが日常生活に当てはまると想像してみてください...

私：こんにちは、私は私の約束のためにここにいます。
受付：申し訳ありませんが、お会いできません。
私：どうして？ 今、約束があります。
受付係：私は知らない肩をすくめる。

少し一般化していますが、FormControlプロパティ値を渡せば、それらの値にもアクセスできるはずです。

少なくとも.requiredプロパティを利用可能にすることを妨げるもの

独自のrequiredバリデーターを作成できるという事実。 Angularはあなたの関数が何をするのかを知ることができません。

100％はそれを理解しています、私はそれが関数に基づいていると言っているのではありません。 フィールドが必須であることを知ることは、構成可能でアクセス可能であり、UIに反映される有効化/無効化を知ることと同じくらい基本的です。
開発者がFormControlを操作するだけで、必要なマーカーを条件付きで表示するなどのことができるように、必要なフィールドに対して同様の機能を取得できるようにするためにできることはありますか？

こんにちは、これは私たちの最新のハックであり、必要な入力を自動的にマークします： https：//stackblitz.com/edit/material-input-auto-required-asterisk。 同じ概念をmat-selectやその他のライブラリにも適用できます。

const _clearValidators = AbstractControl.prototype.clearValidators;
AbstractControl.prototype.clearValidators = function(){
  (this as any).isRequired = false;
  _clearValidators.call(this);
}

const _setValidators = AbstractControl.prototype.setValidators;
AbstractControl.prototype.setValidators = function(newValidator: ValidatorFn | ValidatorFn[] | null): void {
  (this as any).isRequired = false;
  _setValidators.call(this, newValidator);
}

export function isRequired(control: AbstractControl): ValidationErrors | null{
  (control as any).isRequired = true;
  return Validators.required(control);
}

@Directive({ selector: '[matInput]:not([required])' })
export class MatInputRequiredDirective implements DoCheck {
  constructor(private readonly input: MatInput) { }

  ngDoCheck() {
    const isRequired = (this.input.ngControl && this.input.ngControl.control as any).isRequired || false;
    if(isRequired !== this.input.required){
      this.input.required = isRequired;
      this.input.ngOnChanges();
    }
  }
}

100％はそれを理解しています、私はそれが関数に基づいていると言っているのではありません。 フィールドが必須であることを知ることは、構成可能でアクセス可能であり、UIに反映される有効化/無効化を知ることと同じくらい基本的です。

私はちょっと確信が持てません。 「要件」は、アプリケーションのビジネスロジックに非常に固有です。 空の文字列は「必須」条件を通過しますか？ ゼロはどうですか？ 複数選択の空の配列？ チェックボックスが間違っていますか？ ヌル、未定義？

開発者がFormControlを操作するだけで、必要なマーカーを条件付きで表示するなどのことができるように、必要なフィールドに対して同様の機能を取得できるようにするためにできることはありますか？

必要な条件に基づいて、すでに条件付きでエラーを表示/非表示にすることができます。 エラーが存在するからといって、必ずしもどこかに表示する必要があるとは限りません。 ここでは、単にエラー（利用可能）を照会するのではなく、バリデーターを照会することがどのように役立つかわかりません。

私はちょっと確信が持てません。 「要件」は、アプリケーションのビジネスロジックに非常に固有です。 空の文字列は「必須」条件を通過しますか？ ゼロはどうですか？ 複数選択の空の配列？ チェックボックスが間違っていますか？ ヌル、未定義？

有効/無効になっているフィールドもアプリケーションのビジネスロジックに非常に固有であると主張できますが、FormControlは、開発者がコンストラクターとアクセサーを介してそれを管理する機能を提供します。 必要とされるのは曖昧な線であり、私はあなたがどこから来ているのかを理解します。 これは個人的な好みかもしれませんが、値の有効性を示すのと同じくらい、表示状態（有効/無効、有効/無効など）です。

必要な条件に基づいて、すでに条件付きでエラーを表示/非表示にすることができます。 エラーが存在するからといって、必ずしもどこかに表示する必要があるとは限りません。 ここでは、単にエラー（利用可能）を照会するのではなく、バリデーターを照会することがどのように役立つかわかりません。

はい、条件付きでエラーを非表示/表示できますが、これらのエラーが解決されると、期待される状態に依存しないプレゼンテーション部分は使用できなくなります。 バリデーターに基づいてアスタリスクを表示することはできません。これらのバリデーターが満たされると、それらは使用できなくなるためです。
今のところ、私はそれを回避する必要があると思います。

有効/無効になっているフィールドも、アプリケーションのビジネスロジックに非常に固有です。

方法がわかりません。

バリデーターに基づくアスタリスクを表示できません

したがって、代わりに、独自の「必須」セマンティクスに基づいてバリデーターを追加します。 すべてがワンライナーになるわけではありません。

私はシナリオをサポートするための合理的な方法を探していますが、必ずしもワンライナーではありません。 私はまた、私のものがずれている場合に備えて、あなたの視点を理解しようとしています。

私のセマンティクスが単なるバニラであり、Validators.required検証を活用するためだけに必要な場合はどうなりますか？ 以下のStackBlitzの例では、テキストフィールドに追加して値を入力した場合、それを知る唯一の方法は、 field.errorsオブジェクトを介して、バリデーターに関連付けられたプロパティを探すことです。 ただし、Validatorが満たされると、そのプロパティは存在しなくなります。 たぶん私のアプローチは間違っていますが、FormControlを活用して、私が利用していないこれを達成するためのより良い方法はありますか？

StackBlitzの例

別のフィールドの有効性に基づいてバリデーターを切り替えることは想定されていません。 グループバリデーターを作成し、名前とセカンダリ名の両方を含むオブジェクトの値を確認します。 詳細については、このコメントを参照してください。

スターに関しては...まあ、あなたのアプローチは「それはひどい考えだ」という意味で「間違っている」わけではありませんが、それはバリデーターが現在想定している方法では機能しない考えです。 ですから、あなたのアプローチは、フォームが現在どのように使用されると想定されているかと_互換性がない_と言いたいです。

説明した効果をすばやく実現したい場合は、独自のミニフォーム作成ライブラリを作成する必要があります。 これは、この問題に直面した場合に問題にどのように取り組むかについての簡単なスケッチです。 たとえば、次のようなspecオブジェクトを受け入れる関数createFormを作成できます。

spec = {
  name: {
    initialValue: '',
    isRequired: (formValue) => true, // always required
  },
  secondName: {
    initialValue: '',
    isRequired: (formValue) => isFilledIn(formValue.name), // required only if name is filled in
  }

isFilledInは、値が入力されているかどうかを判別する関数です。 おそらくval => val != null && value != ''のようなものです。

このcreateFormは、次のように作成した場合と同じフォームを返します。

this.fb.group({
  name: [''],
  secondName: [''],
}, {
  validators: [
    (group) => {
      const value = group.value
      const errors = {}
      if (spec.name.isRequired(value) && !isFilled(value.name)) {
        errors['name-required'] = true
      }
      if (spec.secondName.isRequired(value) && !isFilled(value.secondName)) {
        errors['secondName-required'] = true
      }
      return errors // or null if no errors found
    }
  ]
})

エラーはグループ自体に発生します。 secondNameのエラーは確かにそこに属します。その有効性は別のフィールドに依存するため、 secondNameを単独で検証することはできません（代わりにそれらのフィールドのグループを検証します）。 nameのエラーは$ nameに属するはずですが、この実装のスケッチはそれをフォームグループに配置します。 これはうまくいくかもしれませんし、うまくいかないかもしれません。 specオブジェクトにフィールドを導入して、このように構成をさらに微調整することができます。

@angular/formsオブジェクトが手元にあるので、テンプレートでは通常どおりフォームを使用します。 フォームグループからのエラーとコントロールからのエラー（または、それが機能する場合はグループからのすべて）を印刷する必要があります。 スターを切り替えるための条件はspec[key].isRequired(form.value)になります。

これをどれだけ正確に実装するかという可能性は無限であり、それはすべて、フォームAPIがすべての人を満足させるとは思わないほどの小さな決定に依存します。 したがって、自分のプロジェクトでフォームに期待する内容に応じて、フォームビルダーの周りに「セマンティック」ラッパーを導入するのが最善です。これにより、要件に基づいて追加の処理が実行されます。

アプローチと前のコメントを参照するために時間を費やしてくれてありがとう、スレッドの歴史はかなり長いです:)

それが私の問題の一部だったと思います。 グループ化されたコントロールとグループ外に存在するコントロール間のフィールドの依存関係を適切に管理します。 スペックアプローチはほとんどの分野で私のフォールバックでしたので、あなたもそれにアプローチする方法であるように思えてうれしいです。

フォームAPIがすべての人を満足させるとは思わない

確かに、提供されているAPIがその種のカバレッジを満たしているかどうかはわかりません。

すべてのアップデート？ この号の作成からほぼ4年。
現在、検証を保存するためのカスタムユーティリティ関数を作成しています。これは、formControlのgetValidatorsのためだけに「バニラ」角度から派生しすぎる関数です。

本当にこの機能が必要になります

これは、リアクティブフォームをラップする使用者にとって非常に役立ちます

非常に貴重なスレッド。 ただし、フォームコントロールのバリデーターにアクセスできないようにすることで、どのような目的を解決するのかについて少し混乱しています。 私はこの要件にぶつかりました。カスタムコンポーネントが必要な場合は「*」を表示する必要があり、そのすぐ下に関連するエラーメッセージが表示される可能性があります（ユーザーがそれを希望する場合）。 もう1つの方法は、ユーザーにテンプレートからプロパティを設定させることで、コントロール自体のAPIに追加することです。 ただし、リアクティブ形式の場合、ユーザーが必要なバリデーター（またはその他のバリデーター）を既に提供しているため、これは必要ありません。 私のカスタムコンポーネントは、そのようなバリデーターが設定されていることを認識でき、それに基づいて要素を表示/非表示にできるはずです。 非常に一般的な要件のようです。

バリデーターに関するすべての情報を持ち、それらのバリデーターを完全に制御できるようにするカスタム構成のカスタムFormControlを使用したソリューション：

export class CustomFormControl extends FormControl {

  public listValidator: CustomValidator[] = [];

  private constructor(formState?: any,
                      validatorOrOpts?: ValidatorFn | ValidatorFn[] | CustomCtrlOpts | null,
                      asyncValidator?: AsyncValidatorFn | AsyncValidatorFn[] | null) {

    super(formState, validatorOrOpts as ValidatorFn[], asyncValidator);

    if (validatorOrOpts instanceof CustomCtrlOpts) {
      this.listValidator = validatorOrOpts.customConf;
    }
  }

  // Builder ith default value
  public static init(formState?: any): CustomFormControl {
    return new CustomFormControl(isNil(formState) ? null : formState);
  }

  public required(): CustomFormControl {
    return this.and('required');
  }

  public email(): CustomFormControl {
    return this.and('email');
  }

  public custom(): CustomFormControl {
    return this.and('custom');
  }

  public min(min: number): CustomFormControl {
    return this.and('min', min);
  }

  public max(max: number): CustomFormControl {
    return this.and('max', max);
  }

  private and(key: TypeCustomValidator, value?: any): CustomFormControl {
    this.listValidator.push({key: key, value: value});
    this.setValidators(new CustomCtrlOpts(this.listValidator).validators as ValidatorFn[]);
    return this;
  }
}

// Add others if needed
export type TypeCustomValidator = 'min' | 'max' | 'required' | 'email' | 'custom' ;

export interface HandledValidator {
  key: TypeCustomValidator;
  function: Function;
  params?: boolean;
}

export const listHandledValidators: HandledValidator[] = [
  {key: 'required', function: Validators.required},
  {key: 'email', function: Validators.email},
  {key: 'min', function: Validators.min, params: true},
  {key: 'max', function: Validators.max, params: true},
  {key: 'custom', function: custom}
];

export interface CustomValidator {
  key: TypeCustomValidator;
  value?: any;
}

export class CustomCtrlOpts implements AbstractControlOptions {

  validators?: ValidatorFn | ValidatorFn[] | null;
  asyncValidators?: AsyncValidatorFn | AsyncValidatorFn[] | null;
  updateOn?: 'change' | 'blur' | 'submit';

  private _customConf?: CustomValidator[];

  constructor(value: CustomValidator[]) {
    this.customConf = value;
  }

  get customConf(): CustomValidator[] {
    return this._customConf;
  }

  set customConf(value: CustomValidator[]) {

    this._customConf = value;

    if (!value) {
      return;
    }

    this.validators = [];

    value.forEach(customValidator => {
      const validator = listHandledValidators.find(it => it.key === customValidator.key);
      if (validator.params) {
        (this.validators as ValidatorFn[]).push(validator.function(customValidator.value) as ValidatorFn);
      } else {
        (this.validators as ValidatorFn[]).push(validator.function as ValidatorFn);
      }
    });
  }
}

次のようなformGroup初期化を使用

this.form = this.fb.group({
    amount: CustomFormControl.init(10).required().min(0), 
    ...

これは本当に素晴らしい機能です。 このための回避策を使用すると、時間の無駄のように感じます。

本当にこの機能が必要になります

ええ、これは本当に必要です。 簡単に言えば、何かを設定する方法があるとしたら、それを無効にする同様の方法もあるはずです。 何かを簡単に設定できるが、それらを取り戻すために多くの労力を費やさなければならない場合、_本当に必要な_何かが明らかに欠けています。

この問題/機能に関する進展はありますか？

@BenKatanHighLander途中です： https ：//github.com/angular/angular/pull/37263#issuecomment -723333060