関連＃11279

これは＃11279とは関係ありません。

それがどのように関連していないか説明してください。
あなたが望むのは、抽象制御が一般的な権利であるということですか？ これが、valueChangesがObservable<any>以外の型を持つことができる唯一の方法であり、型を推測する他の方法はありません。
これはまさに＃5404が求めていることであり、これは＃11279に関連していることを意味します
AbstractControlをジェネリックにすることなくこれを実装できる別の方法がある場合は、それを説明してください。

＃11279のようにget<Type>を使用することは、明らかに間違った解決策です。 TypeScriptにJavaUnbounded Wildcardのようなものがある場合、 getはそれを使用し、 anyは使用しません。 たぶん、空のインターフェイスで同じ方法で何かを行うことができますか？

https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-1.html keyofもあります。 TypeScript 2.1の機能は、強く型付けされたフォームコントロールを実装するために研究するのに非常に興味深いかもしれません。

残念ながら、現在のように大きなアプリに使えるとは思えないので、その上に何かをデザインする必要があります。

TS 2.2（https://github.com/Microsoft/TypeScript/wiki/Roadmap#22-february-2017）で、デフォルトのジェネリック型（https://github.com/Microsoft/TypeScript/）を計画していることに気づきました。我々はこれをしたら問題/ 2175）は、私は私たちが作ることができるので、この問題を再検討することをお勧めかもしれないと思うAbstractControlのような一般的なAbstractControl<T = any>ところTタイプですvalueChangesによって返される値。これはObservable<T>ます。 これは大規模な重大な変更になるため、現在それを行うのは良い考えではありませんが、デフォルトのジェネリックでは、誤解しない限り、重大な変更にはなりません。

これに関する小さな更新は、デフォルトのジェネリックがTS2.3に移動されたよう

デフォルトのジェネリック型を使用したTypeScript2.3はすでにここにありますが、AngularでのTS 2.3のサポートの準備が整う予定はありますか？

@desferoはビルドがTS2.3にアップグレードされるのを＃16707で待機しています

+1はこの機能を見たいと思っています。 誰かがそれに取り組んでいますか？

16828

現在https://github.com/Microsoft/TypeScript/issues/16229でブロックされてい

これは役に立つかもしれません

これに関する小さな更新：
ここでの私のコメントによると： https ：
ジェネリックスを現在のFormsAPIに実装するには、変更を加える必要があります。
したがって、いずれかの重大な変更が必要です
または完全なフォームの書き直し

だから私の前のコメントは間違っていたことがわかりました。
ここに表示されているように、現在のForms APIにこれを実装できました＃20040

@Toxicableは、安全にリファクタリングする機能が不足しているという問題があります。 たとえば、get（ 'person'）は、実際にはシンボル自体を使用していません。 上記の@rpbeukesの例では、基本的にオブジェクトシンボルを使用するように改良されています。 文字列を使用せずにget（obj.person）。 これは、リターンタイプだけを使用するよりも優先されます。

@howiempt

たとえば、get（ 'person'）は、実際にはシンボル自体を使用していません

これが何を意味するのかわかりませんが、ここでどの記号を参照していますか？
私の実装では、次のようなことができます

let g = new FormGroup({
  'name': new FormControl('Toxicable'),
  'age': new FormControl(22),
})

g.get('name') //AbstractControl<string>
g.get('age') //AbstractControl<number>

文字列を使用せずにget（obj.person）

これには、複数のFormGroupをトラバースする機能がありません。
私の方法ではこのシナリオで型を推測することはできませんが、私のPRのアイデアは、変更を壊したり、新しいAPI（ジェネリックを除く）を導入したりせずにジェネリック型を追加することです。

@Toxicableあなたの変化は物事を壊さないことを意味し、あなたの解決策を批判しようとしないことを意味していると私は理解しています。 もう1つの実装（後付け）では、文字列ではなく実際のプロパティを使用できます。 文字列でフィールドを参照することにより、そのプロパティ名が変更された場合、breakが作成されますが、これは私にとってはあまり安全ではありません。 たとえば、フィールド名を「name」から「firstName」に変更すると、すべてのg.get（ 'name'）参照を変更しなかった場合に機能しなくなります。 私が何かをすることができれば

class PersonDetails {
  name: string;
  age: number;
}
let g = new FormGroup<PersonDetails>({
  name: new FormControl('Toxicable'),
  age: new FormControl(22),
})

g.get(name) //AbstractControl<string>
g.get(age) //AbstractControl<number>

それらはすべて厳密な参照になります。 レトロフィットソリューションは少しハックな方法でそれを行いますが、その問題も解決します。

@有毒なPRに

私は@howiemptに同意し

g.get(x => x.name) //AbstractControl

繰り返しになりますが、これがより広い範囲でどれほど実現可能かはわかりません。
私はあなたの判断を信頼します。

良い仕事を続けて、迅速な対応に感謝します。

他のコントロールにアクセスするこの方法は、ジェネリックスの追加とは関係がないと思います。
ただし、それについて別の問題を開いてください

戻り型を設定することが実際には「強く型付けされている」とは思いません。実装の半分が必要なようですが、それは正しい方向への一歩です。

こんにちは、この問題の回避策としてhttps://github.com/Quramy/ngx-typed-formsをリリースしました。 ぜひチェックしてください😄

@Quramy私は数週間前にあなたのパッケージを使おうとしました、そして私が覚えているように、それは実際には多くの強制をしません:(

+1。 実装したかったのにインスタンス数がカウントできません。

同じ。
Angular Reactiveフォームは、他のフレームワークを実際に凌駕する機能の1つです。 リアクティブフォームを強く型付けすると、それが次のレベルになり、競争とのギャップがさらに広がります:)

これは、条件付きマップ型と再帰を使用して実行できます.....条件付きマップ型はtypescriptにマージされました。 これが公開される場合、強い型付きフォームを可能にするチャンスがあります

待てない（

@Quramyソリューションは、残念ながら、すべての引数の構造をFormBuilder強制しません。 また、汎用のFormGroup<T> 、 FormControll<T> 、およびFormArray<T>は、 AbtractControl<T>イベント拡張しないインターフェースであるため、直接使用することはできません。 これは私たちの現在のプロジェクトには十分ではありませんでした。

ngx-strongly-typed-formsを使用して、強い型付きフォームプロジェクトを自分でリリースしました
デフォルトのジェネリックを使用しないため、下位互換性が少し損なわれます。 そのため、コントロールに任意のタイプを明示的に指定する必要がありますが、他のすべての部分にさらに多くのタイプセーフティを追加し、@ angle / formsの現在の実装とAPI互換です。
おそらくこれは、この機能がAngularに実装されるまでは有効な代替手段です。

+1これは強力な機能です。

できるだけ早く実装する必要があります）

コーディングの方法

このオープンソースソフトウェア（AGPL）には興味深い実装があります

https://github.com/concentricsky/badgr-ui/blob/master/src/app/common/util/typed-forms.ts

私はこれを一時的な回避策として使用しました：
それが役に立てば幸い

import { FormControl, AbstractControl } from "@angular/forms";
export class NumberControl extends FormControl{
    _value: Number;
    get value(){ 
        return this._value;
    }
    set value(value){
        this._value = Number(value);
    }
}

これは、私が取り組んだプロジェクトで何度か考えたことですが、JavaScriptプロキシを十分に使用していないため、これらの値を監視するものにパフォーマンスが与える影響を知ることができません。

FormBuilderレベルでカスタム回避策を作成しただけです。

import { Injectable } from '@angular/core';
import { FormBuilder, FormGroup } from '@angular/forms';
type ExtraProperties = { [key: string]: any } | null;
interface IModelConstructor { new(...args: any[]): any }

@Injectable({
    providedIn: 'root'
})
export class TypedFormBuilder {
    array = this.formBuilder.array;
    control = this.formBuilder.control;
    group = this.formBuilder.group;

    constructor(private formBuilder: FormBuilder) {}

    typedGroup<TGroupModel extends object>(ModelType: IModelConstructor, extraProps?: ExtraProperties): FormGroup & TGroupModel {
        const formGroup: any = this.group({
            ...new ModelType(),
            ...extraProps
        });

        return new Proxy<FormGroup & TGroupModel>(formGroup, {
            get: (target: FormGroup & TGroupModel, propName: string | number | symbol) => {
                if (propName in target) {
                    return target[propName];
                } else {
                    const property = target.get(propName as string);
                    return property && property.value;
                }
            },
            set: (target: FormGroup & TGroupModel, propName: string | number | symbol, value: any, _: any) => {
                if (propName in target) {
                    target[propName] = value;
                } else {
                    target.setValue({ [propName]: value });
                }

                return true;
            }
        });
    }
}

このソリューションは完全に洗練されたものではなく、FormGroupで生成されたプロパティの値にアクセスするのがおそらく最善でしょう（myGroup.fieldsなど。「fields」は指定されたタイプになります）。 しかし、これは強い型付けを提供します。 それを使用するには：

generateFormGroup() {
    this.theGroup = builder.typedGroup<MyModel>(MyModel);
    this.theGroup.someProperty = 5;
}

私は、現在のプロジェクトでフォームの入力を使用し

しかし、ジェネリックスを現在のAPIに配置することが正しい決定であるかどうかについて、話し合いたいと思います。 すべてのフォームコントロールの型を作成しているときに、静的型付けはその時点では不可能であり、最大の懸念事項の1つではないと思うため、入力が不可能または扱いにくいエッジケースやものをたくさん見つけました。
残念ながら、これはAbstractControl#valueの主な機能を対象としています。これは、 DeepPartial<T> 、またはサブクラスごとに異なる実装を持つAbstractControl#getようなものでなければなりません。
下位互換性があると、 anyタイプのフォールスルーケースによって引き起こされるタイプの安全性の一部も失われます。
おそらく、リアクティブフォーム用の新しいAPIを検討することも、この問題のオプションですか？

だから、これは実際の解決策が起こっている間に私がやったことです。

免責事項...私はAngularを始めたばかりですが、Typescriptに精通しているため、リアクティブフォームを完全には理解していません...これが私にとってうまくいく結果ですが、もちろん完全ではありません。FormGroupと入力しただけですが、フォームについて詳しく知るにつれて、もっと多くのことを入力する必要があると確信しています...

import { FormGroup } from '@angular/forms';

export class FormGroupTyped<T> extends FormGroup {
  public get value(): T {
    return this.value;
  }
}

そして、私はそれをこのように使うことができます

import { FormGroupTyped } from 'path/to/your/form-group-typed.model';

interface IAuthForm {
  email: string;
  password: string;
}

const authForm: FormGroupTyped<IAuthForm> = fb.group({
  email: ['', [Validators.required]],
  password: ['', [Validators.required]],
});

const formValues: IAuthForm = this.authForm.value;
const email: string = formValues.email; 
const invalidKeyVar: string = formValues.badBoy; // [ts] Property 'badBoy' does not exist on type 'IAuthForm'. [2339]
const invalidTypeVar: number = formValues.password; // [ts] Type 'string' is not assignable to type 'number'. [2322]

@Toxicable Lolはこの正確な問題を探していました！ はは

@cafesanuコンストラクターをチェックするために、型指定されたFormGroupを少し改善しました。

import { AbstractControl, AbstractControlOptions, AsyncValidatorFn, FormGroup, ValidatorFn } from '@angular/forms';

export class FormGroupTyped<T> extends FormGroup {
  readonly value: T;
  readonly valueChanges: Observable<T>;

  constructor(controls: { [key in keyof T]: AbstractControl; },
              validatorOrOpts?: ValidatorFn | Array<ValidatorFn> | AbstractControlOptions | null,
              asyncValidator?: AsyncValidatorFn | Array<AsyncValidatorFn> | null) {
    super(controls, validatorOrOpts, asyncValidator);
  }

  patchValue(value: Partial<T> | T, options?: {
    onlySelf?: boolean;
    emitEvent?: boolean;
  }): void {
    super.patchValue(value, options);
  }

  get(path: Array<Extract<keyof T, string>> | Extract<keyof T, string>): AbstractControl | never {
    return super.get(path);
  }
}

利用方法 ：

export class SearchModel {
  criteria: string;
}

const searchForm = new FormGroupTyped<SearchModel >({
  criteria: new FormControl('', Validators.required) // OK
  badBoy: new FormControl('', Validators.required)  // TS2345: Object literal may only specify known properties, and 'badBoy' does not exist in type '{ criteria: AbstractControl; }'.
});

ビルダーの呼び出しに基づいてデータのタイプを動的に生成できるようにするFromControlの小さなラッパーを作成しました： https ：

動的に構築された型は、インターフェイス型を事前に宣言してから、フォームを作成するための適切な呼び出しを行う必要がなく、フォームの形状が期待に一致することを保証します。

いつかAngularでこれに似たものを見たいです。

使用法は次のようになります。

// Create a typed form whose type is dynamically constructed by the builder calls
const group = new TypedFormGroup()
    .add("firstName", typedControl("", Validators.required))
    .add("lastName", typedControl("", Validators.required))
    .add(
        "address",
        typedGroup()
            .add("street", typedControl("2557 Kincaid"))
            .add("city", typedControl("Eugene"))
            .add("zip", typedControl("97405"))
    )
    .addArray(
        "items",
        typedGroup()
            .addControl("itemName", "")
            .addControl("itemId", 0)
    )
;

// All these are type checked:
group.value.address.street.trim();
group.controls.firstName.value;
group.untypedControls.firstName.value;
group.value.items[0].itemId;

こんにちは、過去3日間、私はd.ts gistを使用して、元の角度クラスと互換性のある新しいTypedインターフェイスを作成するReactiveFormsクラスのより厳密な定義を定義する実験をしてい
私はそれがあなたの問題の可能な解決策/回避策かもしれないと思います😉

//BASIC TYPES DEFINED IN @angular/forms + rxjs/Observable
type FormGroup = import("@angular/forms").FormGroup;
type FormArray = import("@angular/forms").FormArray;
type FormControl = import("@angular/forms").FormControl;
type AbstractControl = import("@angular/forms").AbstractControl;
type Observable<T> = import("rxjs").Observable<T>;

type STATUS = "VALID" | "INVALID" | "PENDING" | "DISABLED"; //<- I don't know why Angular Team doesn't define it https://github.com/angular/angular/blob/7.2.7/packages/forms/src/model.ts#L15-L45)
type STATUSs = STATUS | string; //<- string is added only becouse Angular base class use string insted of union type https://github.com/angular/angular/blob/7.2.7/packages/forms/src/model.ts#L196)

//OVVERRIDE TYPES WITH STRICT TYPED INTERFACES + SOME TYPE TRICKS TO COMPOSE INTERFACE (https://github.com/Microsoft/TypeScript/issues/16936)
interface AbstractControlTyped<T> extends AbstractControl {
  // BASE PROPS AND METHODS COMMON TO ALL FormControl/FormGroup/FormArray
  readonly value: T;
  valueChanges: Observable<T>;
  readonly status: STATUSs;
  statusChanges: Observable<STATUS>;
  get<V = unknown>(path: Array<string | number> | string): AbstractControlTyped<V> | null;
  setValue<V>(value: V extends T ? V : never, options?: { onlySelf?: boolean; emitEvent?: boolean }): void;
  patchValue<V>(value: V extends Partial<T> ? V : never, options?: { onlySelf?: boolean; emitEvent?: boolean }): void;
  reset<V>(value?: V extends Partial<T> ? V : never, options?: { onlySelf?: boolean; emitEvent?: boolean }): void;
}

interface FormControlTyped<T> extends FormControl {
  // COPIED FROM AbstractControlTyped<T> BECOUSE TS NOT SUPPORT MULPILE extends FormControl, AbstractControlTyped<T>
  readonly value: T;
  valueChanges: Observable<T>;
  readonly status: STATUSs;
  statusChanges: Observable<STATUS>;
  get<V = unknown>(path: Array<string | number> | string): AbstractControlTyped<V> | null;
  setValue<V>(value: V extends T ? V : never, options?: { onlySelf?: boolean; emitEvent?: boolean }): void;
  patchValue<V>(value: V extends Partial<T> ? V : never, options?: { onlySelf?: boolean; emitEvent?: boolean }): void;
  reset<V>(value?: V extends Partial<T> ? V : never, options?: { onlySelf?: boolean; emitEvent?: boolean }): void;
}
interface FormGroupTyped<T> extends FormGroup {
  // PROPS AND METHODS SPECIFIC OF FormGroup
  //controls: { [P in keyof T | string]: AbstractControlTyped<P extends keyof T ? T[P] : any> };
  controls: { [P in keyof T]: AbstractControlTyped<T[P]> };
  registerControl<P extends keyof T>(name: P, control: AbstractControlTyped<T[P]>): AbstractControlTyped<T[P]>;
  registerControl<V = any>(name: string, control: AbstractControlTyped<V>): AbstractControlTyped<V>;
  addControl<P extends keyof T>(name: P, control: AbstractControlTyped<T[P]>): void;
  addControl<V = any>(name: string, control: AbstractControlTyped<V>): void;
  removeControl(name: keyof T): void;
  removeControl(name: string): void;
  setControl<P extends keyof T>(name: P, control: AbstractControlTyped<T[P]>): void;
  setControl<V = any>(name: string, control: AbstractControlTyped<V>): void;
  contains(name: keyof T): boolean;
  contains(name: string): boolean;
  get<P extends keyof T>(path: P): AbstractControlTyped<T[P]>;
  getRawValue(): T & { [disabledProp in string | number]: any };
  // COPIED FROM AbstractControlTyped<T> BECOUSE TS NOT SUPPORT MULPILE extends FormGroup, AbstractControlTyped<T>
  readonly value: T;
  valueChanges: Observable<T>;
  readonly status: STATUSs;
  statusChanges: Observable<STATUS>;
  get<V = unknown>(path: Array<string | number> | string): AbstractControlTyped<V> | null;
  setValue<V>(value: V extends T ? V : never, options?: { onlySelf?: boolean; emitEvent?: boolean }): void;
  patchValue<V>(value: V extends Partial<T> ? V : never, options?: { onlySelf?: boolean; emitEvent?: boolean }): void;
  reset<V>(value?: V extends Partial<T> ? V : never, options?: { onlySelf?: boolean; emitEvent?: boolean }): void;
}

interface FormArrayTyped<T> extends FormArray {
  // PROPS AND METHODS SPECIFIC OF FormGroup
  controls: AbstractControlTyped<T>[];
  at(index: number): AbstractControlTyped<T>;
  push<V = T>(ctrl: AbstractControlTyped<V>): void;
  insert<V = T>(index: number, control: AbstractControlTyped<V>): void;
  setControl<V = T>(index: number, control: AbstractControlTyped<V>): void;
  getRawValue(): T[];
  // COPIED FROM AbstractControlTyped<T[]> BECOUSE TS NOT SUPPORT MULPILE extends FormArray, AbastractControlTyped<T[]>
  readonly value: T[];
  valueChanges: Observable<T[]>;
  readonly status: STATUSs;
  statusChanges: Observable<STATUS>;
  get<V = unknown>(path: Array<string | number> | string): AbstractControlTyped<V> | null;
  setValue<V>(value: V extends T[] ? V : never, options?: { onlySelf?: boolean; emitEvent?: boolean }): void;
  patchValue<V>(value: V extends Partial<T>[] ? V : never, options?: { onlySelf?: boolean; emitEvent?: boolean }): void;
  reset<V>(value?: V extends Partial<T>[] ? V : never, options?: { onlySelf?: boolean; emitEvent?: boolean }): void;
}

stackblitzでの使用テスト-コードをダウンロードしてローカルVSCodeで実行してくださいstackblitzでsetValueとpathValueのエラーが正しくない理由がわかりません...

このツイッタースレッドで、いくつかの「将来のアイデア」について@IgorMinarと話し合います（V8 +以降）

コメント、提案、ヘルプは大歓迎です！

私のソリューションは@ng-stack/formsと呼ばれています。 興味深い機能の1つは、フォームタイプの自動検出です。

したがって、コンポーネントでこれを行う必要はありません。

get userName() {
  return this.formGroup.get('userName') as FormControl;
}

get addresses() {
  return this.formGroup.get('addresses') as FormGroup;
}

今これを行います：

// Note here form model UserForm
formGroup: FormGroup<UserForm>;

get userName() {
  return this.formGroup.get('userName');
}

get addresses() {
  return this.formGroup.get('addresses');
}

詳細については、 @ ng-stack / formsを参照してください。

ねえ、私たちは最近@zakhenryと2つのことに取り組んできました：

• フォームタイプの改善
• サブフォームの管理方法の改善（サブコンポーネント内）

@dmorosinottoのようにすべてのタイプを

誰かがlibを調べたい場合： ngx-sub-form

こんにちは@ maxime1992私はControls<T>を見ましたが、それはAbstractControl to <T[K]>厳密にしません
理由を聞いてもいいですか？ 実行時にsetControlやregisterControlメソッドなどを使用してFormControlと関連する型を再定義および変更する必要があると感じたため、「型なし」のままにしますか？
TypedForms.d.tsは少し厳密で、 AbstractControlTyped to the type T<P>を「強制」するためですが、この種の選択で、元のReactiveForms APIで許可され、使用される可能性のあるものを強制/無効にするかどうかはわかりません。誰か...

何か考えはありますか？ 考慮すべき実際のケースはありますか？
これに関するコメントは、私が作成した定義と私が取り組んでいるPRを変更する方法を決定するのに役立つかもしれません...
ありがとう

PS：ngx-sub-formのすばらしい作業👍ControlValueAccessorを使用してサブフォームを処理するというアイデアは、私も実験していたものです😉

@ ng-stack / formsの場合、サポート型の検証が追加されました。

クラスFormControl 、 FormGroup 、 FormArrayおよびFormBuilderすべてのメソッド
ジェネリックの2番目のパラメーターとして「エラー検証モデル」を受け入れます。

class ValidationModel {
  someErrorCode: { returnedValue: 123 };
}
const control = new FormControl<string, ValidationModel>('some value');
control.getError('someErrorCode'); // OK
control.errors.someErrorCode; // OK
control.getError('notExistingErrorCode'); // Error: Argument of type '"notExistingErrorCode"' is not...
control.errors.notExistingErrorCode; // Error: Property 'notExistingErrorCode' does not exist...

デフォルトでは、 ValidatorsModelと呼ばれる特殊なタイプが使用されます。

const control = new FormControl('some value');
control.getError('required'); // OK
control.getError('email'); // OK
control.errors.required // OK
control.errors.email // OK
control.getError('notExistingErrorCode'); // Error: Argument of type '"notExistingErrorCode"' is not...
control.errors.notExistingErrorCode // Error: Property 'notExistingErrorCode' does not exist...

ValidatorsModelは、 typeof Validatorsから抽出されたプロパティのリストと、期待される収益タイプが含まれています。

class ValidatorsModel {
  min: { min: { min: number; actual: number } };
  max: { max: { max: number; actual: number } };
  required: { required: true };
  requiredTrue: { required: true };
  email: { email: true };
  minLength: { minlength: { requiredLength: number; actualLength: number } };
  maxLength: { requiredLength: number; actualLength: number };
  pattern: { requiredPattern: string; actualValue: string };
}

@dmorosinottoどうもありがとうございましたが、使用できません
Validators.compose([Validators.required, Validators.maxLength(20), Validators.minLength(3)])

こんにちは@youssefshariefバリデーターに関する問題の詳細を教えていただけますか？ .d.tsを使用してどのようなエラー/問題を見つけましたか？

サンプルコードまたはstackblitzを投稿できる場合は、それを監視し、解決策が見つかった場合は問題の解決を支援しようとします😉

@ng-stack/forms場合、 input[type="file"]サポートが追加されました。

stackblitzの例も参照してください

FormDataを使用してファイルをアップロードする「クラシック」アプローチも使用しましたが、いくつかの利点があります。

• フォーム入力名を自動的に取得します。例： <input type="file" name="someName"> -> formControl.valueとsomeNameフィールド名。
• フィールド名を適切に設定してmultiple属性をサポートします（ここではuserpic[]注意してください）

<input type="file" multiple name="userpic" [formControl]="formControl">

`` `ts
formData.append（ 'userpic []'、myFileInput.files [0]）;
formData.append（ 'userpic []'、myFileInput.files [1]）;

- `Validators` have four static methods for files
```ts
import { Validators } from '@ng-stack/forms';

Validators.fileRequired;
Validators.fileMaxSize(1024);
Validators.filesMaxLength(10);
Validators.filesMinLength(2);

これまでに見た@KostyaTretyakは、Angular ReactiveFormsでの現在のタイピングの問題に対する優れたソリューションのようです。 独自の実装を行う代わりに、Angular自体に貢献することを考えたことはありますか？

私たちはほぼAngular8にいますが、100％TypeScript環境では、すぐに使用できる型付きフォームがまだありません。これは私にはかなり奇妙に感じます。

@kroeder 、現在の問題が2年以上前に作成されたことがわかります（Angular 2のリリースのほぼ直後）。同様のプルリクエストが1。5年前にマージなしで作成されたことがわかります...

しかし、 @ng-stack/formsが人気があり、Angular 8+と互換性がある場合は、将来的にプルリクエストを作成する可能性があります。

@KostyaTretyakいいですね:)このスレッドで前述し、 @ no0x9dによって作成されたhttps://github.com/no0x9d/ngx-strongly-typed-formsを使用しています。ライブラリはそれとどのように異なりますか？

@ZNS 、わかりませんが、簡単に確認したところ、 ngx-strongly-typed-formsには検証用のジェネリックがなく、フォームコントロールの適切なタイプを自動的に検出することもできないと思い

@ ZNS @ KostyaTretyakこんにちは。 上で述べたように、私はngx-strongly-typed-formsの作者です。
@ng-stack/formsの機能セットを簡単に確認しましたが、いくつかの小さな違いがあると思います。

ほぼすべてのソリューションまたは回避策と私のプロジェクトの間には概念的な違いがあります。
ほとんどの場合、元のAngular FormControlは、プロキシによって拡張またはラップされています。 一部のメソッドは他の型シグニチャーでオーバーライドされ、元の関数に委任されます。
これにより、パフォーマンスへの影響はごくわずかな新しいレイヤーが導入されますが、より重要なのは、維持する必要があり、プロジェクトにバグをもたらす可能性のあるコードです。
私の意見では、これはコンパイル時の静的チェックには不要です。 唯一の実行時の部分は、型指定されたFormBuilderを提供するNgModuleです。これは、実際には元のAngularFormBuilderです。 それ以外はすべてAngularコードです。

直接比較すると、ValidationModelと、オブジェクトからFormGroupsへの変換、およびArraysからFormArraysへの変換はありませんが、型の安全性を高め、バリデーター引数を型付けするために、 AbstractControl#getにいくつかの意見の変更を行いました。

いくつかの小さな追加で、私のコードは下位互換性があり、プルリクエストを作成できます。 しかし、同様のプルリクエストは長い間古くなっています。
しかし、Angularでこれを実現するための努力があれば、私は力を合わせて喜んでいます。 反対に、厳密に型指定されるように設計されたフォーム用の新しいAPIを見てみたいと思います。 詳細については私のコメントを参照してください。

+1はこの機能を見たいと思っています。 誰かがそれに取り組んでいますか？

角度のあるチームにぶつかる？

彼らは開発者を気にしません。 彼らは、ブラックジャックと素晴らしい-5％減少バンドルサイズの機能を備えた独自のバックログを持っています。

@ Lonli-Lokli

彼らは開発者を気にしません。

批判は簡単です。 他の開発者をもっと気にしますか？
フォームを改善するためのPRや、物事を前進させるための建設的なコメントやRFCを見たことがありません：man_shrugging：

彼らは独自のバックログを持っています

まさか：恐ろしい：！
人々は会社が_ [彼らにお金を払っている] _が必要とするものを優先していますか？
残念だ！

素晴らしい-5％-バンドルサイズの機能を減らします。

あなたは明らかにアイビーと（現在）バンドルサイズの非常に小さな違いについて話している。
アイビーは現在実験的であり、オプトインする必要があります。驚くべきことに、まだ完璧ではありません。 ：考え：
はい、Ivyはバンドルサイズを縮小し、ツールがアプリでより良いツリーシェイクを実行できるようにするのに役立つと言われています。 そしてうまくいけば、それが来るでしょう！ 今のところ、彼らはそれが何かを壊していないことを確認するためだけに取り組んでおり、後でより良いデバッグ情報、モジュールベースではなくコンポーネントベースでのインクリメンタルコンパイル、およびツリーシェイクを行うのに役立ちます。 しかし、そのツリーを揺さぶるツールは後で機能します。

したがって、敬意を払い、オープンソースフレームワークを無料で提供している人々をゴミ箱に捨てないようにしてください。 物事は完璧ではなく、進行中の巨大な作業です。確かに、いくつかの問題が残されているように感じますが、そのリファクタリングが必要であり、そのような大きなものを作るのに良い時間は決してありません。それはある時点で起こらなければなりませんでした。

非生産的なことについて話しているこのスレッドを独占したくないので、今私はこの議論から外れています。 *飛び去ります*

@ maxime-allex
他にもたくさんのPRがありますが（現在386）、もう1つは何かを変えると思いますか？
この問題について言えば、この関連するPR（https://github.com/angular/angular/pull/20040）はまだマージされていません。

リファクタリングと言えば、Ivyは1年前に言及されました。 誰かが扱うことができるのは開発者にとっての主要な機能であることを私は知っていますが、個人的には、修正ができるだけ多くの開発者にとって重要であることを望んでいます。
https://github.com/angular/angular/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

Angularがマーケティングではなく開発者向けであり、コミュニティの反応に基づいてより多くの問題が解決されることを期待しています。 それが私の質問です。ここでの優先事項は何ですか。

明らかに、この問題は既存のAPIを更新することで解決できますが、これとは別に、ReactiveFormsModuleを改善して、この問題を含む多くの未解決の問題に対処する提案を作成しました。

対処されるその他の問題には、任意のプロパティの更新をサブスクライブする機能や、（ asyncValidatorではなく）サービスを介してコントロールを非同期的に検証する機能が含まれます。 詳細については、＃31963をご覧ください。 フィードバックを歓迎します！

以前に約束したように、プルリクエストを作成しました。 このPRには、 @ng-stack/forms機能の一部のみが含まれています（検証、フォーム制御の自動検出、input [file]のサポートは含まれていません）。

ねえ、Angularチームからの最新情報を共有したいと思います。これは大きな問題点だと聞いています。 間もなく、より強く型付けされたフォームの作業を開始します。これには、既存のPRを確認し、すべてのコメントを再度確認することが含まれます。 時間を割いて考えを残してくれた皆さんに感謝します！

ああ！！！！！ 終了します！

それは非常に良いニュースです、Angularチーム、ありがとう！
リリースがあり次第、 angular-typesafe-reactive-forms-helperを廃止します。

YESSSS !!!!

私はとても興奮しています！！ ありがとう、Angularチーム!!

反応スパムで止められますか？
https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/を対象としているため、反応には絵文字を使用して

Angularチームは、強く型付けされたリアクティブフォームに取り組むことを確認しました。 スムーズな静的型付き開発エクスペリエンスを得るために、 infer型を

最初のアプローチ：値型から始めます

FormGroupのデザインを始めたとき、私は直感的な単純な値型をTとして使用しました。

FormGroup<{ id: string, username: string | null }>

しかし、複雑なテーブルフォームアーキテクチャを処理する必要がある場合、AngularHTMLでタイプセーフなバインディングを実行するのは非常に難しいことがわかりました。

type User = { id: string, username: string | null }
const table: FormArray<User> = new FormArray([{ id: '0', username: 'gaplo917'}])

const row: FormGroup<User> = table.at(0) as FormGroup<User> // you must do a type cast

// NO way to get type-safe binding in Angular HTML
<input [formControl]="table.at(i).controls.id" />

上記の実装では、開発者は面倒でエラーが発生しやすいカスタム型キャストを実行する必要がありました。 私見、これは強く型付けされたリアクティブフォームを使用する理由を完全に失います。

2番目のアプローチ：ControlTypeから開始

単純な値型を使用するとスムーズに機能しません。 KeyValueControlを使用する別のアイデアを思いつきますTおよび使用infer KeyValueControlから抽出値型を再帰的に。

export type KeyValueControl<V> = {
  [key in keyof V]: V[key] & AbstractControl
}

export type InferTypedForm<Type> = Type extends TypedFormControl<infer X>
  ? X
  : Type extends Array<TypedFormControl<infer X1>>
  ? X1[]
  : Type extends Array<TypedFormGroup<infer X2>>
  ? Array<InferTypedFormGroup<X2>>
  : Type extends TypedFormGroup<infer X3>
  ? InferTypedFormGroup<X3>
  : Type extends TypedFormArray<infer X4>
  ? Array<InferTypedForm<X4>>
  : never

export type InferTypedFormGroup<T> = { [key in keyof T]: InferTypedForm<T[key]> }

export type InferTypedFormArray<T> = InferTypedForm<T[]>

export class TypedFormGroup<T extends KeyValueControl<T>> extends FormGroup {
  readonly controls: T
  readonly valueChanges: Observable<InferTypedFormGroup<T>>
  readonly statusChanges: Observable<FormStatus>
  readonly value: InferTypedFormGroup<T>
  ...
}

結果として、

interface Foo {
  first: TypedFormControl<string | null>
  last: TypedFormControl<string | null>
}

const table: FormArray<FormGroup<Foo>>

const row: FormGroup<Foo> = table.at(0) // typescript compile OK!

// type-safe binding in Angular HTML, all auto-complete (`id`, `username`) finally works!
<input [formControl]="table.at(0).controls.id" />

ライブデモ

ライブデモIDEのスクリーンショット

これは、複雑な形式での真のオートコンプリートエクスペリエンスです。

角度型フォーム

既存のリアクティブフォームモジュールと100％互換性があります
https://github.com/gaplo917/angular-typed-forms

コメントや改善を歓迎します。 今後の強く型付けされたリアクティブフォームが、テーブルやネストされたサブフォームなどの複雑なフォームモデルを処理できることを願っています。

@ IgorMinar 、 Angularコアチーム、およびAngularコミュニティメンバー。

この長いコメントは、チケット作成者が「慣習に反する」と「強くタイプされた」という2つのステートメントに完全に焦点を当てています。

強く型付けされたリアクティブフォームのインターフェイスベースのアプローチの代わりに、クラスベースのアプローチを選択することをお勧めしますが、 ng-stacks / formsに記載されている方法では選択しないでください。 また、Angular Ractive Formsのコードベースを変更することはお勧めしません。これは、さまざまな方法でコードベースを変更しなくても、強く型付けされたフォームを実現できるためです。 インターフェイス駆動型アプローチとクラス駆動型アプローチで見られる高レベルの課題は他のものよりも直感的であり、FormGroupオブジェクトは強く型付けされています。 どちらの場合も、FormGroupオブジェクトは強く型付けされており、クラスベースのアプローチでTypeScriptTypeの能力を失うことはありません。

私のおすすめ

私たち全員がOOPプラクティスに精通しているので、このクラスはコードの柔軟性と保守性を向上させます。 以下で強調している利点のいくつか：

1. コードを切り離します。
2. 現在のアプローチおよびインターフェース駆動型アプローチと比較して、コードが少なくなっています。
3. プロパティでカスタムデコレータを使用できます。
4. コードは、読み取り可能で、保守可能で、拡張可能です。
5. このアプローチでは、エラーメッセージを表示するための複数の条件を使用して*ngIfを配置するように、テンプレートにビジネスロジックを記述する必要はありません。 テンプレートはビジネスロジックを書くためのものではないと思います。
6. より多くの...

上記のインターフェイスコードをClass変換し、検証デコレータをClassプロパティに適用します。 ここでは、単一責任原則の実践に従っています。 以下のコードをご覧ください。

いくつかのケースを考えて、両方の違いを理解するのに役立つインターフェースおよびクラス駆動型の強い型のアプローチと比較してみましょう。

1.フォームグループを作成します
ここでは、同じインスタンスを使用しているFormBuilderと同じ方法group 。 しかし、インポートモジュール名は次のように異なるものになりますReactiveTypedFormsModuleの代わりにReactiveFormsModule 。 FormGroup作成しましょう：

上記のコードに従って、質問が来ます、

ReactiveTypedFormsModuleインポートした後、現在のアプローチは機能しますか？
はい、動作します。 ReactiveTypedFormsModuleインポートした後は何も変更されません。

他のケースをすばやく見て、この投稿を締めくくりましょう。

2.FormControlの値を変更します
setValueメソッドを呼び出す代わりに、 Classプロパティに値を直接割り当てることができます。 FormControl値が自動的に設定されます。

3.FormControlの値の変更に基づいてビジネスロジックを実行します
FormControl ValueChangesをサブスクライブする代わりに、TypeScriptのsetterメソッドの力を使用してください。

4.入力値を変換します
強い型に焦点を当てていますが、日付のように入力コントロールから取得される値についてはどうでしょうか。 String形式で値を取得していますが、TSコードではDate形式を期待しています。この問題を克服するために、必要に応じて値を変換するディレクティブまたはメソッドを作成します。 ディレクティブを作成して何とか何とかする必要があるため、現在のコードは少し不器用なので、ここでは示しません。😄そこで、クラス駆動型アプローチのコードをここに示します。

@toDate() // this will convert the value before assigning the value in 'dob' property.
dob:Date;

4.ネストされたFormGroupFormControlの値を変更します
ネストされたFormGroupオブジェクトを取得してSetValueメソッドを呼び出すのではなく、それぞれのプロパティに値を直接割り当てることができます。

5.ネストされたFormArrayにFormGroupを追加する
これ以上言うことはありません、以下のコードを見てください😄。

HTMLテンプレートでFormGroupオブジェクトを参照する

シンプルなコード😄。 HTMLテンプレートでは何も変更されませんが、HTMLテンプレートでもさらに変更されます。 以下のコードを参照してください

<form [formGroup]="user.formGroup">
   <input type="text" formControlName="firstName"/>
   <small >{{user.formGroup.controls.firstName.errorMessage}}</small>
<!--Nested FormGroup-->
   <div [formGroup]="user.address.formGroup">...</div>
<!--Nested FormArray - Skills-->
   <div *ngFor="let skill of user.skills">
       <div [formGroup]="skill.formGroup">...</div>
   </div
</form>

Stackblitz Link ：強いタイプの反応型フォームの作業例
Githubの例：強く型付けされたリアクティブフォーム

@ajayojha 、私が間違っている場合は訂正してください。

1. TypeScriptタイプに伴うオーバーヘッドは悪いです。
2. デコレータの助けを借りたランタイム検証-それは良いことです。
3. セッター/ゲッターがいるのに、なぜsetValue()とvalueChanges()必要なのですか？

私はどう思いますか：

1. TypeScriptタイプの記述は、静的テストの記述に似ています。 不必要だと思ってテストなしでアプリケーションを作成する人もいるかもしれませんが、それは悪い習慣です。
2. デコレータの助けを借りたランタイム検証-それは良い考えかもしれません、同意します。
3. setValue()に加えて、 patchValue() 、 reset()もあり、これらはフォーム値でも機能します。 setValue()のみをセッターに置き換えると、コードに一貫性がなくなります。 さらに、フォームモデルプロパティごとにセッターを作成する必要がある場合、ゲッターの場合のパフォーマンスオーバーヘッドだけでなく、コードオーバーヘッドも大幅に増加します。 フォームモデルのプロパティ名とフォームコントロールのプロパティを混在させることも、私の意見では悪い考えです。

@KostyaTretyak 、私のコメントに懸念をお寄せいただきありがとうございます。同じように回答させていただきます。それに応じて、以下のコメントをご覧ください:)。

1. TypeScriptタイプに伴うオーバーヘッドは悪いです。

参考までに、formgroupオブジェクトは強く型付けされています。 インターフェイスは優れていますが、すべての領域に適しているわけではありません。TypeScriptの型が悪いと言っているわけではありません。どこかで、型が悪いと言ったことはないと思います。 私の唯一の懸念はインターフェースに関するものです。なぜなら、インターフェースアプローチでソフトウェア設計の慣行を覆しているからです。あるいは、間違った場所でインターフェースアプローチを使用していて、私の提案するアプローチはクラスであると言えます。 クラスアプローチによる私の理解の限りでは、インターフェイスで得られるTypeScriptタイプの利点を損なうことはありません。あるいは、読みやすさ、スケーラビリティ、および保守性の点で、インターフェイスアプローチ以上のものを得ることができます。

強く型付けされた反応型フォームのインターフェースの正しい方法を使用していますか？

インターフェースの観点からもう少し説明させてください。これは、強く型付けされたリアクティブフォームの悪い習慣です（私によると）。

TypeScriptタイプは優れていますが、インターフェイスの問題について明確に述べたように、ソフトウェアの慣例に従わないものをどこでも混乱させる必要があることは示唆されていません。 インターフェースに関する私の強調された懸念について考えてみてください。 私のケースを共有しましょう。6k以上のコンポーネントを含む私のエンタープライズアプリケーションの1つです。 インターフェイスアプローチを使用する場合、開発チームは変更を行う前に良い質問をします。

• 同じエンティティが異なるプロパティを持つ複数のコンポーネントで使用されているため、どのインターフェイスをどこで使用する必要があるか。 次に、個別のインターフェイスコンポーネントを作成する必要がありますか？ はいの場合は、2番目のケースをお読みください。
• 上記のアプローチを使用する場合、1つまたは多くのコンポーネントで両方のインターフェイスプロパティを使用する必要があるアプローチはどうなりますか。 この懸念を解決するために、もう1つのインターフェースを作成し、同じものを拡張することができます。 強いタイプの反応型フォームを振るためだけに、より多くのファイルを作成するのは良いことですか？ 保守性についてはどうですか？、Angularチームがこのソリューションを提供しているということを除いて、私には答えがありません：）（Angularチームがインターフェイスアプローチを選択する場合）。
• a + bアプローチを使用する場合、一部のコンポーネントでは、すべてではなく、いくつかのプロパティが必要でした。 開発チームに提供するソリューションは3つあります。
  
  
  
  • 新しいインターフェイスを作成し、新しく作成したインターフェイスに必要なプロパティをコピーして貼り付けます。 これは、ソフトウェアの世界で最も汚いアプローチです。 これにより、サーバー側で単一のプロパティが変更される場合に多くの問題が発生し、プロパティ名を変更するインターフェイスの数を同様に追跡することが困難になります。
  
  
  • プロパティをnull許容に設定します。 null許容プロパティを定義している場合、なぜ「B」アプローチに従う必要があるのですか？ 繰り返しますが、私には答えがありません:(私の開発チームに与えるために。
  
  
  • 別のインターフェイスを作成せず、「部分的」ユーティリティタイプを使用し、すべてのプロパティをオプションにします。 これを行うことにより、インターフェースの実際の利点が失われます。 これも慣行に反します。 私がこれに従わなければならないのなら、なぜ私は「A」アプローチに従わなければならないのか、やはり答えはありません:)。
  
  
  • すべて/少数のプロパティをnull許容にする場合、コードの可読性と、サーバーに値を渡すために必要なプロパティの数をどのように判断できますか？ 次に、それぞれのコンポーネントをチェックインして、垣間見る必要があります。 主要なコードの可読性の懸念。
  
  

ここで、上記のケースをより大きな視点で考え、強く型付けされたリアクティブフォームのインターフェイスを備えたTypeScriptタイプと比較します。 私は、すべての優れたアプローチが開発時間を節約すると信じており、このアプローチでは、ソフトウェア設計の原則と実践によると、何のメリットも見られないと言って申し訳ありません。

1. デコレータの助けを借りたランタイム検証-それは良いことです。

「それは良い」というあなたのコメントに同意します。インターフェイスアプローチでは達成できないデコレータアプローチです。 これがTypeScriptの最も強力な機能であると私は信じています。それなら、なぜリアクティブフォームアプローチで同じものを使用できず、開発チームにオブジェクトプロパティの完全な制御を与えることができないのですか。

1. セッターがあるのになぜsetValue（）が必要なのですか？

'setValue（）'が必要だと言ったところは？ setValueは必要ありません。また、クラスドリブンアプローチでsetValueメソッドを呼び出す例には示していません。 私が間違っている場合は訂正してください。

1. TypeScriptタイプの記述は、静的テストの記述に似ています。 不必要だと思ってテストなしでアプリケーションを作成する人もいるかもしれませんが、それは悪い習慣です。

TypeScriptタイプが静的テストを書くようなものだと言っているのではありません。 しかし、リアクティブフォームの基本クラスでのコミットの変更には同意しません。クラス定義に触れることなく同じことを達成できると思います。 ここでは、これまでのコミットに従って使用していないインターフェイスの実際の能力を使用できます。これは、ロジックが長時間実行され、デフォルト値の 'を設定してジェネリック型を追加することをお勧めします。どれか'？
Reactive Formの基本クラスに触れることなく、同じことを達成できると思います。 基本クラスの定義を変更したり、仕様を変更したりする代わりに、なぜこれでインターフェイスを利用しないのかわかりません。

1. デコレータの助けを借りたランタイム検証-それは良い考えかもしれません、同意します。

私たち二人ともこのページで同じページであることを知っておくとよいでしょう:)。

1. setValue（）に加えて、patchValue（）、reset（）もあります。これらは、フォーム値でも機能します。 setValue（）のみをセッターに置き換えると、コードに一貫性がなくなります。 さらに、フォームモデルのプロパティごとにセッターを作成する必要がある場合は、パフォーマンスのオーバーヘッドだけでなく、コードのオーバーヘッドも大幅に増加します。 フォームモデルのプロパティ名とフォームコントロールのプロパティを混在させることも、私の意見では悪い考えです。

上記の点を、メソッドの呼び出し、セッターのパフォーマンスオーバーヘッド、およびフォームモデルプロパティの混合の3つのセクションで説明します。

メソッドの呼び出し：予想どおり、この投稿を書いているときに、誰かが「patchValue」または「reset」メソッドの使用を提案する可能性があると考えていました。 繰り返しになりますが、実際のケースでは、ほとんどの開発チームがpatchValueやその他のメソッドの代わりに「setValue」メソッドを使用しています（これは、Angular Application CodeReviewおよびStackoverflowPostsのsetValueとpatchValueによる私の経験です）。 私の焦点は、どのメソッドを呼び出しているかに関係なく、値を割り当てるためのメソッドを呼び出すことです。

セッターのパフォーマンス：@Inputデコレータを使用して複数のコンポーネントで使用しているのと同じアプローチのもう1つは、この種のパフォーマンスの問題を克服するために、代替チームまたはAngularチームが別のソリューション（私は信じています）を提供する必要があることを見つける必要があります。 ですから、これは大きな問題ではないと思います。 パフォーマンスの問題については、既存のアプローチとセッターメソッドのアプローチを比較してください（これはオプションです。開発チームは、AngularのChangeDetectionStrategyと同じように選択できます。選択については、rxwebドキュメントサイトの例を参照してください。この場合、値の変更をサブスクライブするときに呼び出している関数の数を判断し、値を設定した後、またはsetterメソッドを直接呼び出した後、値の変更に比べてコードの実行が少なく、ビルドのサイズが小さいという点で、これははるかに直感的だと思いますパッケージ、コードの読みやすさ、その他多くの優れた点。

プロパティの混合：それで、あなたの意見は、サーバーが返したプロパティ名とは異なるFormControlプロパティ名を割り当てているということです。 はいの場合、サーバーに投稿する前にプロパティ名を変更する必要があるため、これはコードの大きな問題であると言えます。申し訳ありませんが、アプリケーション全体でプロパティ名を変更することは望ましくありません。 平均40以上のフィールドを含む私のアプリケーションフォームに対するあなたの良い意見を考えると、すべてのプロパティ値を手動で設定する必要があります。値と製品ビルドサイズを割り当てるためのコンポーネントのコードについて考えてみてください。 これはクラスアプローチよりも良い意見ですか？
ここで、提案されたソリューションについて説明します。2つのものを1つに混合しているわけではありません。 FormControlプロパティは異なり、クラスプロパティはそれぞれのデータ型とは異なります。 FormControlプロパティ名がDataプロパティと異なるなど、プロパティ名を変更する場合は、rxwebリアクティブフォームパッケージのドキュメントを参照してください。 したがって、提案されたアプローチでは、悪い感じ（プロパティ名とフォームコントロール名の混合）が解決策になるため、問題はありません。

私はあなたの懸念のすべてに答えたことを願っています、これに関する他の懸念があれば遠慮なく共有してください:)。

以前のコメントで述べたように、Reactive Formの基本クラスを変更する必要はありません。これは、インターフェイス分離の原則の実践の力を使用して同じことを達成できるためです。 これは、 @ rxweb / typesのパッケージを使用したエンドツーエンドの強い型の反応型ソリューションです。 これは、インターフェイスおよびクラスアプローチでうまく機能します:)。

実装後のコードはどのように見えますか？

Stackblitz：オープン
Github ：インターフェース駆動型の強い型のリアクティブフォームの例

誰かが同じことを自由に共有する提案があります。

したがって、 Angularのバージョン10が利用可能になりました。これはメジャーリリースであり、明らかにリアクティブなフォームは、少なくともAngularのバージョン11まで強く型付けされません。 したがって、この機能を実装するには、少なくとも秋まで待つ必要があります。

ここで見たほとんどの提案/ PRでフォームモデルを構築する方法について質問（または提案？）があります。

Reactive Formsタイプを安全にしようとしているほとんどのライブラリとPRを見ると、次のようなモデルが作成されていることがわかります。

interface Address {
  name: Name;  
}
interface Name {
  firstName: string;
  lastName: string;
}

次に、これは次のようなものに「変換」されます。

const myForm = new FormGroup<Address>({
  name: new FormGroup<Name>({
    firstName: new FormControl('John'),
    lastName: new FormControl('Doe'),
  })
})

つまり、簡単に言うと、「オブジェクトの場合は、そのためのFormGroupを作成します。配列の場合は、FormArrayを作成します。プリミティブ値の場合は、FormControlを作成します。」

ただし、1つの問題があります。FormControlsでオブジェクトを使用できなくなりました。

私がこれまでに見た解決策：一部のライブラリは単にこれをサポートしていません。 また、一部のライブラリは、ある種の「ハック」を使用して、FormGroupの代わりにFormControlを実際に使用したいというヒントを作成します。

私の質問/提案：フォームモデルを次のように明示的に定義することに反対するものは何ですか？

interface Address {
  name: FormGroup<Name>;  
}
interface Name {
  firstName: FormControl<string>;
  lastName: FormControl<string>;
}

const myForm = new FormGroup<Address>({
  name: new FormGroup<Name>({
    firstName: new FormControl('John'),
    lastName: new FormControl('Doe'),
  })
})

これには、オブジェクトをFormControlsに配置できるという大きな利点があります。 そして、そうするためにどんな種類の「ハック」も必要としません:)

このためのCodesandboxを作成したので、自分で試してみることができます： https ：//codesandbox.io/s/falling-grass-k4u50？file = / src / app / app.component.ts

@MBuchalik 、はい、これは「強い型のフォーム」で作業を開始したときに頭に浮かぶ最初の明白な決定です。 私もこれから始めましたが、これには重大な欠点があります。1つはフォームコントロール用、もう1つはフォーム値用の2つのモデルを作成する必要があります。

一方、私が理解している限り、このソリューションでは、変更を壊すことなく「強い型のフォーム」を実装でき、Angularの次のメジャーバージョンのリリースを待つ必要はありません。 ここでは、このようなソリューションを実際に使用して、2つのモデルを作成する必要性よりも重大な欠点があるかどうかを評価する必要があります。

@MBuchalik私はあなたと同じ意見を共有し、 PRに同じ質問を提起し、角度のある貢献者の1人（ @KostyaTretyak ）が回答しました。

あなたはPRの議論を見るかもしれません：
https://github.com/angular/angular/pull/37389#discussion_r438543624

TLDR;

ここにいくつかの問題があります：
あなたのアプローチに従う場合、フォームコントロール用とフォーム値用の2つの異なるモデルを作成する必要があります。
フォームコントロールのモデルは読みにくいです。

そして、私は半年前にすでに本番環境で使用されてfullTemplateTypeCheck有効になっている場合）

私はこのスレッドの以前のコメントで「なぜ私がこのように行くのか」を共有しました：
https://github.com/angular/angular/issues/13721#issuecomment -643214540

Codesanboxデモ： https ：//codesandbox.io/s/github/gaplo917/angular-typed-form-codesandbox/tree/master/？fontsize = 14＆hidenavigation = 1＆theme = dark

@KostyaTretyakと@ gaplo917の洞察に感謝します！ 👍

正しく理解できれば、次のようにまとめることができます。

単一のモデルのみを使用する場合は、 @ KostyaTretyakが提供するようなソリューションを使用できます。 ただし、欠点は、FormControlsでオブジェクトを使用できなくなったことです。 （これを可能にする「ハック」があることは知っています。しかし、モデルは再び「クリーン」ではないため、もう一度2つのモデルが必要になります。）

FormControlsでオブジェクトを使用できるようにしたい場合は、おそらく（！）図のようなアプローチを使用する方法はありません（または@ gaplo917）。 欠点は、基本的に2つのモデルが必要なことです。 または、少なくともいくつかのヘルパータイプを使用して、フォーム値モデルを「抽出」します。

したがって、FormControlsのオブジェクトが可能かどうかを考える必要があります。 これは、2つのアプローチのどちらを選択するかに関する質問に答えるだけです。 それとも私は何かが足りないのですか？

@KostyaTretyakと@ gaplo917の洞察に感謝します！ 👍

正しく理解できれば、次のようにまとめることができます。

単一のモデルのみを使用する場合は、 @ KostyaTretyakが提供するようなソリューションを使用できます。 ただし、欠点は、FormControlsでオブジェクトを使用できなくなったことです。 （これを可能にする「ハック」があることは知っています。しかし、モデルは再び「クリーン」ではないため、もう一度2つのモデルが必要になります。）

FormControlsでオブジェクトを使用できるようにしたい場合は、おそらく（！）図のようなアプローチを使用する方法はありません（または@ gaplo917）。 欠点は、基本的に2つのモデルが必要なことです。 または、少なくともいくつかのヘルパータイプを使用して、フォーム値モデルを「抽出」します。

したがって、FormControlsのオブジェクトが可能かどうかを考える必要があります。 これは、2つのアプローチのどちらを選択するかに関する質問に答えるだけです。 それとも私は何かが足りないのですか？

@MBuchalik私の意見では、 用意する必要はありません。 内部システムには60以上のフォームがあり、そのうちのいくつかは3つの深さレベルFormArray-FormGroup-FormArrayネストされた非常に複雑であり、値型の明示的なモデルも必要ありません。

使用できるデータモデルは2種類のみです。

• APIデータ要求/応答モデル
• FormControlモデル

99.9％の時間、私たちは

1. 複雑なフォームごとにカプセル化を作成します
2. リモートデータの変換->フォームデータ
3. フォームデータの変換->リモートペイロード

次のコードスニペットは図です。

interface FooApiData {
   id: string
   age: number
   dob: string | null
   createdAt: string
}

interface FooFormControlType {
  id: TypedFormControl<string>
  age: TypedFormControl<number>

  // calendar view required JS date form control binding
  dob: TypedFormControl<Date | null>
} 

interface FooApiUpdateRequest {
   id: string
   dob: string | null
   age: number
}

class FooForm extends TypedFormGroup<FooFormControlType> {
    constructor(private fb: TypedFormBuilder, private initialValue: FooApiData) {
      super({
          id: fb.control(initialValue.id, Validators.required),
          dob: fb.control(initialValue.dob === null ? new Date(initialValue.dob) : null),
          age: fb.number(initialValue.age, Validators.required)
       })
   }
   toRequestBody(): FooApiUpdateRequest {
       const typedValue = this.value
       return {
          id: typedValue.id,
          dob: typedValue.dob !== null ? moment(typedValue.dob).format('YYYYMMDD') : null,
          age: typedValue.age
       }
   }
}

const apiData = apiService.getFoo()

const form = new FooForm(new TypedFormBuilder(), apiData)

// assume some UI changes the form value
function submit() {
   if(form.dirty && form.valid){
     const payload = form.toRequestBody()
     apiService.updateFoo(payload)
   }
}

PSこれは、Typescriptでタイプセーフにプログラミングを楽しむことができる意見のあるデータフローアーキテクチャです。

単一のモデルのみを使用する場合は、 @ KostyaTretyakが提供するようなソリューションを使用できます。 ただし、欠点は、FormControlsでオブジェクトを使用できなくなったことです。 （これを可能にする「ハック」があることは知っています。しかし、モデルは再び「クリーン」ではないため、もう一度2つのモデルが必要になります。）

ここでも、 FormControlオブジェクトを使用する必要がある頻度を見積もる必要があります。 どこかで5〜30％と見積もることができると思います。 つまり、1つのモデルでソリューションを使用する場合、 FormControlを使用するケースの70〜95％をカバーできます。 残りの部分については、TypeScriptのヒントを追加のタイプとして提供するだけです（ Control<T> 、これを「2番目のモデル」と呼ぶのは正しくありません）。

interface FormModel {
  date: Control<Date>;
}

Control<T>タイプはハックと呼ぶことができますか？ -はい、それはおそらくハックですが、大まかなハックではありません。 このタイプが意図したとおりに機能しない、または副作用がある場合はわかりません。

ああ、フォーム値モデルに外部ライブラリを使用する必要がある場合のControl<T>副作用を思い出しました。 このような場合、2つのモデルが実際に必要です。

import { FormBuilder, Control } from '@ng-stack/forms';

// External Form Model
interface ExternalPerson {
  id: number;
  name: string;
  birthDate: Date;
}

const formConfig: ExternalPerson = {
  id: 123,
  name: 'John Smith',
  birthDate: new Date(1977, 6, 30),
};

interface Person extends ExternalPerson {
  birthDate: Control<Date>;
}


const fb = new FormBuilder();
const form = fb.group<Person>(formConfig); // `Control<Date>` type is compatible with `Date` type.

const birthDate: Date = form.value.birthDate; // `Control<Date>` type is compatible with `Date` type.

しかし、このコードでは、オーバーヘッドはここにのみあります。

interface Person extends ExternalPerson {
  birthDate: Control<Date>;
}

@ArielGuetaのおかげで、 Control<T>タイプの重大な問題が判明しました。 つまり、以前に計画したように、Angularの将来のプルリクエストでControl<T>を実装しようとさえしません。

@ArielGuetaのおかげで、 Control<T>タイプの重大な問題が判明しました。 つまり、以前に計画したように、Angularの将来のプルリクエストでControl<T>を実装しようとさえしません。

@KostyaTretyakそれは真実ではありません。 重要な問題は、「ControlType」の実装が正しくないことを示しているだけです。

完全な「制御タイプ」の実装には問題はありません。

ライブデモ： https ：//codesandbox.io/s/lucid-bassi-ceo6t = / src / app / demo / forms / type -test.ts

つまり、私はコントロールを実装しようとさえしません以前に計画したように、将来のAngularのプルリクエスト。

OK、つまり、PR（および連続するPR）はFormControlsのオブジェクトをサポートしない可能性が高いということですか？

@MBuchalik 、現時点（Angular v10）、次のフォームモデルがある場合：

interface FormModel {
  date: Date;
}

また、コンポーネントでdateプロパティの値にアクセスする場合は、次の手順を実行する必要があります。

get date() {
  return this.formGroup.get('date') as FormControl;
}
// ...
this.date.value as Date;

私の現在のプルリクエストは、フォーム値のジェネリックを提供しますが、フォームコントロールのタイプを提供しません。

get date() {
  return this.formGroup.get('date') as FormControl<Date>;
}
// ...
this.date.value; // Here Date type

@ gaplo917、@MBuchalik、私はあなたのソリューションを試みたが、私自身の同様のソリューションを実装しようとしましたが、それらはすべて完璧に動作しませんしました。 このソリューションは、フォームモデル値を再帰的に抽出するための一連のタイプも提供します。 オーバーヘッドと重大な変更は非常に重要です。PRドラフトを参照してください。

現時点では、これらのソリューションをAngularで実装するように提案する必要があるかどうかは非常に疑わしいです。 つまり、今のところ、ジェネリックスはフォームコントロールタイプではなく、フォーム値にのみ使用する必要があります。

しかし、それらはすべて完全には機能しません

イラストに数時間しか費やしていないので、完璧だとは思っていませんでした;）うまくいかないことの例を教えてください。 （特に、あなたの観点から、簡単に修正できないものについては？）

ところで、下位互換性に関する1つの提案：私の観点からは、実装を完全に下位互換にすることは比較的困難です。 このため、次のことができる可能性があります。FormControl、FormGroup、およびFormArrayクラスはまったく変更しません。 代わりに、それらを継承する新しいものを作成します（おそらく、それらをStrictFormControl<T>およびStrictFormGroup<T>などと呼びます）。 これらは、タイプセーフにするものです。 利点：重大な変更が行われないことを100％確信しています。 :)

私のイラストは数時間なので、完璧だとは思っていませんでした;）

私はこのソリューションを数日間使用しましたが、フォームを使用するのがどれほど難しいかがわかります。

1. まず第一に、かなりのオーバーヘッドと2つのモデルが必要です。
2. 次に、このソリューションは、信頼性の点でControl<T>タイプのソリューションよりも優れていません。これは、同じ方法でフォームモデルの値を再帰的に抽出する必要があるためです。
3. ネストされたフォームコントロールを操作します。 次のフォームモデルがある場合：

interface FormModel {
  one: FormGroup<{two: FormControl<string>}>;
}

そして、 formGroup.controls.one.valueを取得した場合、TypeScriptは、 {two: string}タイプではなく、条件付きタイプでヒントを提供します（本来あるべき姿です）。 したがって、IDEから読み取るのは難しい価値があります。

そして、formGroup.controls.one.valueを取得すると、TypeScriptは、{two：string}型ではなく、条件付き型のヒントを提供します（本来あるべき姿）。 したがって、IDEから読み取るのは難しい価値があります。

OK、それで私がすべてを正しく理解したことを確認するためだけに。 私の実装を使用して、次のように記述した場合：

interface FormModel {
  one: FormGroup<Two>;
}
interface Two {
  two: FormControl<string>;
}

const myForm = new FormGroup<FormModel>({
  one: new FormGroup<Two>({
    two: new FormControl('')
  })
});

（もう少し冗長にしました;））

myForm.controls.one.valueを探すと、次のようになります。

つまり、この例では、「2つ」はオプションではないということですか？ これはフォームの値を入力する正しい方法ではないと思います。 フォームの値には、無効になっていないフィールドのみが含まれます。 したがって、私の観点からは、再帰的なパーシャルである必要があります。 コンパイル時に、どのフィールドが無効になり、どのフィールドが無効になるかを知ることはできません。

つまり、この例では、「2つ」はオプションではないということですか？

何？ いいえ。

あなたのソリューションの私のテスト：

interface FormModel {
  one: FormGroup<{two: FormControl<string>}>;
}

let formGroup: FormGroup<FormModel>;
const some = formGroup.controls.one.value;

valueマウスを置いた後に

(property) FormGroup<FormGroupControls<{ two: FormControl<string>; }>>.value: PartialFormGroupValue<FormGroupControls<{
    two: FormControl<string>;
}>>

ここで、 PartialFormGroupValueは、条件付きタイプPartialFormValue指します。

ああ、わかりました、私はそれを手に入れたと思います。 つまり、タイプが読みにくいということですか？ 私はもともとあなたがバグやそのような何かについて話していると思っていました。

さて、ほとんどのIDEは、入力を続けると、利用可能なプロパティの提案を表示するだけです。 ですから、ここでは大きな問題は見られません。 （もちろん、 {two?: string}とだけ書かれている場合は、読んだほうがよいでしょう。しかし、これはそれほど重要ではないと思います。少なくとも私の意見です。）

Control<T>を実装した場合、私が行ったようにsthを実行せずに、フォーム値の入力からそれをどのように削除しますか？ また、ヘルパータイプを使用せずに、フォーム値を再帰的パーシャルにするにはどうすればよいでしょうか。

コントロールを実装した場合、それでは、私が行ったようにsthを実行せずに、フォーム値の入力からそれをどのように削除しますか？ また、ヘルパータイプを使用せずに、フォーム値を再帰的パーシャルにするにはどうすればよいでしょうか。

この場合、私の解決策は良くありません：

(property) FormGroup<FormGroup<{ two: FormControl<string>; }>>.value: ExtractGroupValue<FormGroup<{
    two: FormControl<string>;
}>>

あなたがそれを求めたので、私はこの例を与えました：

うまくいかないことの例を挙げていただけますか？ （特に、あなたの観点から、簡単に修正できないものについては？）

ちなみに、 Control<T>重大な問題を修正しました。

Angular 10と[formControl]でのHTMLバインディングの問題を解決するために、これが私が行ったルートです。

別の問題（https://github.com/angular/angular/issues/36405#issuecomment-655110082）に記載されているように、私のフォームでは通常、再利用性とテストを容易にするためにFormGroupを拡張するクラスを作成します。 その構造で、次のようなコードを更新することで、今のところ問題を解決することができました。

class UserFormGroup extends FormGroup {
  constructor() {
    super({
      id: new FormControl(null, Validators.required),
      name: new FormControl(null, Validators.required),
    });
}

これに：

// everything will extend these two
export class EnhancedFormGroup<T extends { [key: string]: AbstractControl }> extends FormGroup
{
  controls!: T;
}
export class EnhancedFormArray<T extends AbstractControl> extends FormArray 
{
  controls!: T[];
}

// reworked form from above
function formDefinition() {
   return {
      id: new FormControl(null, Validators.required),
      name: new FormControl(null, Validators.required),
    };
}

class UserFormGroup extends EnhancedFormGroup<ReturnType<typeof formDefinition>> {
  constructor() {
    super(formDefinition());
}

その時点で、 form.controlsはそのタイプを{ id: FormControl, name: FormControl }として正しく表示し、HTMLで正しくバインドし、フォームがネストされたフォームグループまたは配列でより複雑な場合は正しく集約されます。

formDefinition関数を使用するのは見栄えがよくありませんが、フォーム定義とコンストラクターの間の重複を防ぐために私が思いついた最もクリーンなソリューションでした。

FormGroupを更新して、重大な変更を導入せずに上記のジェネリック型の定義を設定できると思います（まあ、これは、コントロールを動的に追加/削除するフォームには当てはまらない可能性があります。 controlsは表示されません。

編集
FormGroupを拡張するクラスを作成する必要がない場合は、さらに簡単に見えます。 一般的な問題を解決するヘルパー関数を作成できます。

function createEnhancedFormGroup<T extends { [key: string]: AbstractControl }>(controls: T) {
  return new EnhancedFormGroup<T>(controls);
}

const form = createEnhancedFormGroup({
  id: new FormControl(null, Validators.required),
  name: new FormControl(null, Validators.required),
});

編集2
...または、 FormGroupクラス自体にベイクすることもできます（ FormBuilderかもしれませんか？）

export class EnhancedFormGroup<T extends { [key: string]: AbstractControl }> extends FormGroup
{
  controls!: T;

  static create<T extends { [key: string]: AbstractControl }>(controls: T) {
    return new EnhancedFormGroup<T>(controls);
  }
}

const form = EnhancedFormGroup.create({
  id: new FormControl(null, Validators.required),
  name: new FormControl(null, Validators.required),
});

編集3
上記の例を拡張して、 valueの入力を含め、すべてを要約する記事を作成しました。

https://medium.com/youngers-consulting/angular-typed-reactive-forms-22842eb8a181

これは現在、将来の開発のロードマップにマークされています：

@pauldraper約2か月前のロードマップと比較して何が変わったか説明して

@MBuchalikおそらくそれは2ヶ月間そこにありました。