संबंधित #11279

यह #11279 से संबंधित नहीं है।

कृपया बताएं कि यह कैसे संबंधित नहीं है?
आप क्या चाहते हैं कि सार नियंत्रण सामान्य अधिकार हो? यही एकमात्र तरीका है कि valueChanges का एक प्रकार हो सकता है जो Observable<any> नहीं है, इस प्रकार का अनुमान लगाने का कोई अन्य तरीका नहीं होगा।
जो वास्तव में #5404 पूछ रहा है, जिसका अर्थ है कि यह #11279 . से संबंधित है
यदि कोई अन्य तरीका है तो इसे AbstractControl को सामान्य बनाए बिना कार्यान्वित किया जा सकता है, कृपया इसे समझाएं।

## get<Type> का उपयोग करना जैसा कि #11279 में है, निश्चित रूप से गलत समाधान है। यदि टाइपस्क्रिप्ट में जावा अनबाउंडेड वाइल्डकार्ड जैसा कुछ होता, तो get इसका उपयोग करता, न कि any । हो सकता है कि खाली इंटरफेस के साथ उसी तरह से कुछ किया जा सके?

https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-1.html keyof । टाइपस्क्रिप्ट 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 में स्थानांतरित कर दिया गया है। तो संस्करण 4.0 के साथ कोणीय द्वारा टीएस 2.1 के समर्थन के साथ यह उसके बाद लंबे समय तक नहीं होना चाहिए इससे पहले कि वे टीएस 2.3 का समर्थन करने में सक्षम हों, जो अब है जब हमें इसे फिर से देखने के लिए इंतजार करना चाहिए।

डिफ़ॉल्ट जेनेरिक प्रकारों के साथ टाइपस्क्रिप्ट 2.3 पहले से ही यहाँ है, क्या हमारे पास कोई योजना है जब कोणीय में TS 2.3 के लिए समर्थन तैयार होगा?

@desfero #16707 पर प्रतीक्षा कर रहा है कि बिल्ड को TS2.3 में अपग्रेड किया जाए

+1 इस सुविधा को देखना पसंद करेंगे। कोई इस पर काम कर रहा है?

16828

वर्तमान में https://github.com/Microsoft/TypeScript/issues/16229 पर अवरुद्ध है

यह काम का हो सकता है - कोणीय प्रकार सुरक्षित प्रतिक्रियाशील प्रपत्र

इस पर छोटा अपडेट:
यहाँ मेरी टिप्पणी के अनुसार: https://github.com/angular/angular/pull/16828#issuecomment -337034655
वर्तमान प्रपत्र API में जेनरिक को लागू करना परिवर्तनों को तोड़े बिना संभव नहीं है।
तो या तो ब्रेकिंग बदलाव की जरूरत है
या एक पूर्ण रूप फिर से लिखना

तो पता चला कि मेरी पिछली टिप्पणी गलत थी।
मैं इसे मौजूदा फॉर्म एपीआई पर लागू करने में सक्षम था जैसा कि आप यहां देख सकते हैं #20040

@Toxicable जिसमें अभी भी सुरक्षित रूप से रिफैक्टर करने की क्षमता की कमी की समस्या है। get('person') उदाहरण के लिए, वास्तव में प्रतीक का ही उपयोग नहीं कर रहा है। उपरोक्त उदाहरण, @rpbeukes से , मूल रूप से वस्तु प्रतीक का उपयोग करने का एक रेट्रोफिटेड तरीका है। get(obj.person) स्ट्रिंग का उपयोग किए बिना। इसे केवल रिटर्न प्रकार रखने पर प्राथमिकता दी जाएगी।

@howiemp

get('person') उदाहरण के लिए, वास्तव में स्वयं प्रतीक का उपयोग नहीं कर रहा है

मुझे नहीं पता कि आपका इससे क्या मतलब है, आप यहाँ किस प्रतीक की बात कर रहे हैं?
मेरे कार्यान्वयन में आप कुछ ऐसा कर सकते हैं

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

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

स्ट्रिंग का उपयोग किए बिना (obj.person) प्राप्त करें

इसमें कई फॉर्मग्रुप्स को पार करने की क्षमता का अभाव है।
जबकि मेरी विधि इस परिदृश्य में प्रकारों का अनुमान लगाने में असमर्थ है, मेरे पीआर का विचार जेनेरिक प्रकारों को बिना किसी बदलाव या किसी नए एपीआई (जेनेरिक से अलग) को पेश किए बिना जोड़ना है।

@Toxicable मैं समझता हूं कि आप बदलाव का मतलब चीजों को नहीं तोड़ना है, न कि आपके समाधान की आलोचना करने की कोशिश करना। अन्य कार्यान्वयन (रेट्रोफिटेड) एक वास्तविक संपत्ति को एक स्ट्रिंग के बजाय उपयोग करने की अनुमति देता है। फ़ील्ड को स्ट्रिंग द्वारा संदर्भित करके, यदि वह संपत्ति का नाम बदलता है, तो ब्रेक बनाता है, जो मेरे लिए बहुत सुरक्षित नहीं है। उदाहरण के लिए, यदि मैं सभी 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>

वे सभी कड़े संदर्भ होंगे। रेट्रोफिट सॉल्यूशन इसे थोड़े हैकी तरीके से करता है लेकिन उस समस्या को भी हल करता है।

@ पीआर के लिए

मैं @howiempt से सहमत

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

दोबारा, मैं वास्तव में नहीं जानता कि चीजों के बड़े दायरे में यह कितना व्यवहार्य है।
मुझे आपकी समझ पर भरोसा है।

अच्छा काम जारी रखें और त्वरित प्रतिक्रिया के लिए धन्यवाद।

मुझे लगता है कि अन्य नियंत्रणों तक पहुँचने का यह तरीका जेनरिक जोड़ने से संबंधित नहीं है।
हालांकि इसके बारे में एक और मुद्दा खोलने के लिए स्वतंत्र महसूस करें

मैं वास्तव में नहीं सोचता कि रिटर्न टाइप सेट वास्तव में "दृढ़ता से टाइप किया गया" है, ऐसा लगता है कि आधे कार्यान्वयन की आवश्यकता है, लेकिन यह सही दिशा में एक कदम है।

नमस्ते, मैंने इस समस्या के समाधान के लिए https://github.com/Quramy/ngx-typed-forms जारी किया है। कृपया इसे देखें

@Quramy मैंने कई सप्ताह पहले आपके पैकेज का उपयोग करने की कोशिश की थी और जैसा कि मुझे याद है, यह वास्तव में बहुत अधिक प्रवर्तन नहीं करता है :(

+1। जब मैं चाहता था कि इसे लागू किया गया था, तो उदाहरणों की मात्रा की गणना नहीं कर सकता।

वैसा ही।
कोणीय प्रतिक्रियाशील रूप एक ऐसी विशेषता है जो वास्तव में किसी भी अन्य ढांचे को मात देती है। प्रतिक्रियाशील रूपों को दृढ़ता से टाइप करने से यह अगले स्तर पर आ जाएगा, और प्रतिस्पर्धा के अंतर को और चौड़ा कर देगा :)

यह सशर्त मैप किए गए प्रकारों और रिकर्सन के साथ किया जा सकता है ..... सशर्त मैप किए गए प्रकारों को केवल टाइपस्क्रिप्ट में विलय कर दिया गया था। अगर इसे प्रकाशित किया जाएगा तो हमारे पास मजबूत टाइप किए गए फॉर्म को संभव बनाने का मौका है

इंतजार नहीं कर सकता (

@Quramy समाधान दुख की बात है कि सभी तर्कों की संरचना को FormBuilder लागू नहीं करता है। साथ ही सामान्य FormGroup<T> , FormControll<T> और FormArray<T> सीधे उपयोग नहीं किया जा सकता है, क्योंकि वे केवल ऐसे इंटरफेस हैं जो AbtractControl<T> विस्तार नहीं करते हैं। यह हमारी वर्तमान परियोजना के लिए पर्याप्त नहीं था।

एनजीएक्स-दृढ़ता से टाइप किए गए फॉर्मों के साथ मैंने अब एक मजबूत टाइप किए गए फॉर्म प्रोजेक्ट को स्वयं जारी किया है
यह पश्चगामी संगतता के साथ थोड़ा टूट जाता है, क्योंकि यह डिफ़ॉल्ट जेनरिक का उपयोग नहीं करता है। तो यह आपको अपने नियंत्रणों को किसी भी प्रकार का स्पष्टीकरण देने के लिए मजबूर करता है, लेकिन अन्य सभी भागों में बहुत अधिक प्रकार की सुरक्षा जोड़ता है और एपीआई @ कोणीय/रूपों के वर्तमान कार्यान्वयन के साथ संगत है।
शायद यह एक वैध विकल्प है जब तक कि यह सुविधा एंगुलर में लागू नहीं हो जाती।

+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);
    }
}

यह कुछ ऐसा है जिसके बारे में मैंने उन परियोजनाओं में कुछ बार सोचा है जिन पर मैंने काम किया है, लेकिन मैंने प्रदर्शन प्रभाव को जानने के लिए जावास्क्रिप्ट प्रॉक्सी का पर्याप्त उपयोग नहीं किया है जो इन मूल्यों को देखने वाले किसी भी चीज़ पर होगा।

मैंने फॉर्मबिल्डर स्तर पर बस एक कस्टम वर्कअराउंड बनाया है:

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;
            }
        });
    }
}

यह समाधान निश्चित रूप से सुपर पॉलिश नहीं है, और शायद यह सबसे अच्छा होगा कि फॉर्मग्रुप ने किसी संपत्ति पर मूल्यों तक पहुंच प्राप्त की हो (जैसे कि myGroup.fields, जहां "फ़ील्ड" प्रदान किया गया प्रकार होगा)। लेकिन यह मजबूत टाइपिंग प्रदान करता है। इसके प्रयेाग के लिए:

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

मैंने अपने वर्तमान प्रोजेक्ट में अपने फॉर्म टाइपिंग का उपयोग करके पिछले महीनों में टाइप किए गए फॉर्मों के साथ अनुभव एकत्र किया। तीन डेवलपर टीमों के साथ एक प्रोजेक्ट पर काम करते समय यह बहुत अच्छा मूल्य प्रदान करता है और सभी ने स्विच किया क्योंकि ऐसा करना वास्तव में सस्ता था।

लेकिन मैं चर्चा करना चाहता हूं, अगर जेनरिक को मौजूदा एपीआई पर रखना सही निर्णय है। सभी प्रपत्र नियंत्रणों के लिए प्रकारों का निर्माण करते समय, मुझे बहुत सारे किनारे के मामले और ऐसी चीजें मिलीं जो टाइप करने के लिए असंभव या बोझिल हैं, क्योंकि मुझे लगता है कि उस समय स्थिर टाइपिंग संभव नहीं थी और इसलिए सबसे बड़ी चिंताओं में से एक नहीं थी।
अफसोस की बात है कि यह AbstractControl#value साथ मुख्य कार्यक्षमता को लक्षित करता है, जो प्रत्येक उपवर्ग के लिए अलग-अलग कार्यान्वयन के साथ DeepPartial<T> या AbstractControl#get जैसा कुछ होना चाहिए।
पीछे की ओर संगत होने से any प्रकार के मामलों में गिरावट के कारण होने वाली कुछ प्रकार की सुरक्षा भी खो जाती है।
शायद प्रतिक्रियाशील रूपों के लिए एक नए एपीआई पर विचार करना भी इस समस्या का एक विकल्प है?

तो, वास्तविक समाधान होने पर मैंने यही किया।

अस्वीकरण ... मैंने अभी एंगुलर में शुरुआत की है, लेकिन टाइपस्क्रिप्ट से काफी परिचित हूं, इसलिए मैं प्रतिक्रियाशील रूपों को पूरी तरह से समझ नहीं पा रहा हूं ... यहां मेरे लिए काम करना समाप्त हो गया है, लेकिन निश्चित रूप से यह पूरी तरह से पूर्ण नहीं है, मैंने अभी फॉर्म ग्रुप टाइप किया है, लेकिन मुझे यकीन है कि फॉर्म के बारे में और जानने के लिए मुझे और चीजें टाइप करने की आवश्यकता होगी ...

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 यहां कंस्ट्रक्टर की जांच के लिए आपके टाइप किए गए फॉर्मग्रुप का थोड़ा सुधार है।

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://github.com/concentricsky/badgr-ui/blob/develop/src/app/common/util/ typed-forms.ts

गतिशील रूप से निर्मित प्रकार यह सुनिश्चित करता है कि फ़ॉर्म का आकार इंटरफ़ेस प्रकार को पूर्व-घोषित करने के बजाय आपकी अपेक्षाओं से मेल खाता है और फिर आशा है कि आप फ़ॉर्म बनाने के लिए सही कॉल करेंगे।

मैं किसी बिंदु पर कोणीय में ऐसा कुछ देखना पसंद करूंगा।

उपयोग इस तरह दिखता है:

// 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 का उपयोग करके प्रयोग कर रहा था
मुझे लगता है कि यह आपकी समस्या के लिए एक संभावित समाधान/समाधान हो सकता है

//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;
}

स्टैकब्लिट्ज में उपयोग परीक्षण - कृपया कोड डाउनलोड करें और स्थानीय वीएससीओडी में चलाएं मुझे नहीं पता कि स्टैकब्लिट्ज पर सेटवैल्यू और पथवैल्यू के लिए त्रुटियां सही क्यों नहीं हैं ...

इस ट्विटर थ्रेड पर मैं कुछ "भविष्य के विचारों" (V8+ के बाद) के @IgorMinar के साथ चर्चा करता

किसी भी टिप्पणी, सुझाव और मदद का बहुत स्वागत है !

मेरा समाधान @ng-stack/forms कहलाता है। दिलचस्प विशेषताओं में से एक प्रपत्र प्रकारों का स्वचालित पता लगाना है।

तो, आपके घटकों में ऐसा करने की आवश्यकता नहीं है:

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 देखें

अरे, हम हाल ही में 2 चीजों पर @zakhenry के साथ काम कर रहे हैं:

• प्रपत्र प्रकारों में सुधार
• उप प्रपत्रों को प्रबंधित करने के तरीके में सुधार (उप घटकों के भीतर)

हम @dmorosinotto के सभी प्रकारों को कवर नहीं करते हैं, लेकिन हमारे पास कुछ सुरक्षा है जो निश्चित रूप से रिफैक्टर बनाने में मदद

अगर कोई lib पर एक नज़र डालना चाहता है: ngx-sub-form

नमस्ते @ maxime1992 मैंने Controls<T> लेकिन यह AbstractControl to <T[K]> सख्त नहीं करता है
क्या मैं आपसे पूछ सकता हूँ क्यों? क्या आप इसे "अनटाइप्ड" छोड़ देते हैं क्योंकि आपको फॉर्मकंट्रोल और शायद संबंधित प्रकार को फिर से परिभाषित करने और बदलने के लिए सेटकंट्रोल या रजिस्टरकंट्रोल विधियों जैसे कुछ का उपयोग करके रन-टाइम पर प्रकार बदलने की आवश्यकता महसूस होती है?
क्योंकि मेरा TypedForms.d.ts थोड़ा सख्त है और AbstractControlTyped to the type T<P> "बल" देता है, लेकिन मुझे नहीं पता कि इस तरह की पसंद के साथ कुछ ऐसा लागू/अक्षम करें जो मूल ReactiveForms API में अनुमत है और शायद इसके द्वारा उपयोग किया जाता है कोई आ...

कोई सोच? विचार करने के लिए कोई वास्तविक मामला?
इस पर कोई भी टिप्पणी मुझे यह तय करने में मदद कर सकती है कि मैंने जो परिभाषाएं बनाई हैं और जिस पीआर पर मैं काम कर रहा हूं, उसे कैसे बदला जाए ...
धन्यवाद

पीएस: एनजीएक्स-सब-फॉर्म पर बहुत अच्छा काम सबफॉर्म को संभालने के लिए ControlValueAccessor का उपयोग करने का विचार कुछ ऐसा है जिसे मैं भी प्रयोग कर रहा था

@ एनजी-स्टैक/फॉर्म के लिए जोड़ा गया समर्थन टाइप किया गया सत्यापन।

कक्षाएं FormControl , FormGroup , FormArray और FormBuilder सभी तरीके
जेनेरिक के लिए दूसरे पैरामीटर के रूप में "त्रुटि सत्यापन मॉडल" स्वीकार करें:

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)])

हाय @youssefsharif क्या आप मुझे सत्यापनकर्ताओं के साथ अपनी समस्या के बारे में अधिक जानकारी दे सकते हैं? .d.ts का उपयोग करके आपको किस प्रकार की त्रुटि/समस्या का पता चला?

यदि आप एक नमूना कोड या स्टैकब्लिट्ज पोस्ट कर सकते हैं तो मैं इसे देख लूंगा और अगर मुझे कोई समाधान मिल गया तो मैं समस्या को हल करने में मदद करने की कोशिश करूंगा

@ng-stack/forms लिए input[type="file"] लिए अतिरिक्त

स्टैकब्लिट्ज पर भी

मैंने फ़ाइलों को अपलोड करने के लिए 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 मैंने अब तक आपके पैकेज को जो देखा है, वह

हम लगभग कोणीय 8 में हैं और अभी भी 100% टाइपस्क्रिप्ट वातावरण में कोई आउट-ऑफ-द-बॉक्स टाइप नहीं है जो मुझे बहुत अजीब लगता है।

@kroeder , मैं सिर्फ यह देखता हूं कि वर्तमान मुद्दा दो साल से अधिक पहले (लगभग कोणीय 2 के रिलीज के तुरंत बाद) बनाया गया था, और मैं देखता हूं कि इसी तरह का पुल अनुरोध 1.5 साल पहले बिना मर्ज के बनाया गया था ...

लेकिन अगर @ng-stack/forms लोकप्रिय और कोणीय 8+ के साथ संगत होगा, तो शायद मैं भविष्य में पुल अनुरोध बनाउंगा।

@KostyaTretyak बहुत अच्छा लगता है :) मैं https://github.com/no0x9d/ngx-strongly-typed-forms का उपयोग कर रहा हूं जिसका उल्लेख इस थ्रेड में पहले किया गया है और @no0x9d द्वारा बनाया गया है आपकी लाइब्रेरी

@ZNS , मुझे नहीं पता, लेकिन एक त्वरित समीक्षा के बाद, मुझे लगता है कि ngx-strongly-typed-forms में सत्यापन के लिए कोई सामान्य नहीं है, साथ ही फ़ॉर्म नियंत्रण के लिए स्वचालित रूप से

@ZNS @KostyaTretyak नमस्ते। जैसा कि ऊपर उल्लेख किया गया है, मैं ngx-दृढ़ता से टाइप किए गए रूपों का लेखक
मैंने @ng-stack/forms के फीचर सेट की त्वरित समीक्षा की और मुझे लगता है कि कुछ छोटे अंतर हैं।

लगभग सभी समाधानों या वर्कअराउंड और मेरी परियोजना के बीच एक वैचारिक अंतर है।
ज्यादातर मामलों में मूल कोणीय फॉर्मकंट्रोल को कुछ प्रॉक्सी द्वारा बढ़ाया या लपेटा जाता है। कुछ विधियों को अन्य प्रकार के हस्ताक्षरों के साथ ओवरराइड किया जाता है और मूल कार्य के लिए प्रत्यायोजित किया जाता है।
यह एक नगण्य प्रदर्शन प्रभाव के साथ एक नई परत पेश करता है, लेकिन अधिक महत्वपूर्ण कोड है जिसे बनाए रखा जाना है और आपकी परियोजना में बग पेश कर सकता है।
मेरी राय में संकलन समय पर स्थिर जांच के लिए यह अनावश्यक है। एकमात्र रन टाइम पार्ट NgModule है जो मेरा टाइप किया गया फॉर्मबिल्डर प्रदान करता है, जो वास्तव में मूल कोणीय फॉर्मबिल्डर है। बाकी सब सिर्फ कोणीय कोड है।

प्रत्यक्ष तुलना में मेरे पास ValidationModel और ऑब्जेक्ट से FormGroups और Arrays से FormArrays में रूपांतरण नहीं है, लेकिन इसे और अधिक सुरक्षित बनाने और सत्यापनकर्ता तर्क टाइप करने के लिए AbstractControl#get कुछ विचारों में बदलाव किया है।

कुछ छोटे परिवर्धन के साथ मेरा कोड पीछे की ओर संगत हो सकता है और मैं एक पुल अनुरोध बना सकता हूं। लेकिन एक समान पुल अनुरोध लंबे समय से पुराना है।
लेकिन अगर एंगुलर में इसे प्राप्त करने के प्रयास हैं तो मुझे सेना में शामिल होने में खुशी होगी। दूसरी तरफ मुझे उन रूपों के लिए एक नया एपीआई देखना अच्छा लगेगा जो सख्ती से टाइप करने के लिए बेहतर तरीके से डिजाइन किए गए हैं। विवरण के लिए मेरी टिप्पणी देखें।

+1 इस सुविधा को देखना पसंद करेंगे। कोई इस पर काम कर रहा है?

कोणीय टीम के लिए टक्कर?

उन्हें डेवलपर्स की परवाह नहीं है। उनका अपना बैकलॉग है, जिसमें लाठी और भयानक-5%-कमी-बंडल-आकार की विशेषताएं हैं।

@ लोनली-लोकली

उन्हें डेवलपर्स की परवाह नहीं है।

आलोचना करना आसान है। क्या आप अन्य देवों की अधिक परवाह करते हैं?
फ़ॉर्म में सुधार के लिए आपसे कोई पीआर नहीं देखा और न ही किसी प्रकार की रचनात्मक टिप्पणी या चीजों को आगे बढ़ाने के लिए आरएफसी देखा :man_shrugging:

उनका अपना बैकलॉग है

कोई रास्ता नहीं :भयभीत :!
लोग उन चीज़ों को प्राथमिकता दे रहे हैं जिनकी कंपनी _[उन्हें भुगतान कर रही है]_ की ज़रूरत है?
कितनी शर्म की बात है!

भयानक-5%-कमी-बंडल-आकार की विशेषताएं।

आप स्पष्ट रूप से आइवी और (वर्तमान में) बंडल आकार में बहुत छोटे अंतर के बारे में बात कर रहे हैं।
आइवी वर्तमान में प्रयोगात्मक है और आपको इसमें शामिल होना होगा। क्या आश्चर्य की बात है कि चीजें अभी भी परिपूर्ण नहीं हैं! :विचारधारा:
हां, यह बताया गया है कि आइवी बंडल के आकार को कम करने में मदद करेगा और टूल को ऐप्स पर बेहतर ट्री शेकिंग करने की अनुमति देगा। और उम्मीद है, वह आएगा! अभी के लिए वे केवल यह सुनिश्चित करने पर काम कर रहे हैं कि यह कुछ भी तोड़ नहीं रहा है और बाद में बेहतर डिबगिंग जानकारी, मॉड्यूल आधार के बजाय घटक आधार पर वृद्धिशील संकलन, और पेड़ हिलाने में मदद कर सकता है। लेकिन उस पेड़ को हिलाने के लिए टूलींग बाद में काम आएगी।

इसलिए कृपया सम्मानजनक बनने का प्रयास करें और उन लोगों को ट्रैश करने से बचें जो आपको मुफ्त में ओपन सोर्स फ्रेमवर्क दे रहे हैं। चीजें सही नहीं हैं, बहुत बड़ा काम चल रहा है, हां ऐसा लगता है कि कुछ मुद्दे पीछे छूट गए हैं, लेकिन उस रिफ्लेक्टर की जरूरत थी और किसी चीज को इतना बड़ा बनाने के लिए कभी भी अच्छा समय नहीं होगा, यह बस किसी बिंदु पर होना था।

अब मैं इस बहस से बाहर हो गया हूं क्योंकि मैं गैर-उत्पादक चीजों के बारे में बात करने वाले इस धागे पर एकाधिकार नहीं करना चाहता। *उड़ जाना*

@ मैक्सिमे-एलेक्स
कई अन्य पीआर हैं (अभी तक 386), क्या आपको लगता है कि एक और कुछ बदलेगा?
इस मुद्दे की बात करें तो, यह संबंधित पीआर (https://github.com/angular/angular/pull/20040) अभी भी विलय नहीं हुआ है।

रिफैक्टरिंग की बात करें तो आइवी का जिक्र साल पहले किया गया था। मुझे पता है कि कोई भी इलाज कर सकता है डेवलपर्स के लिए एक प्रमुख विशेषता है, लेकिन व्यक्तिगत रूप से मैं यह देखना पसंद करता हूं कि जितने संभव हो उतने डेवलपर्स के लिए फिक्स महत्वपूर्ण हैं।
https://github.com/angular/angular/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

मुझे अब भी उम्मीद है कि एंगुलर डेवलपर्स के लिए है, मार्केटिंग के लिए नहीं, और समुदाय की प्रतिक्रिया के आधार पर और अधिक मुद्दों को बंद करने की उम्मीद है। यही मेरा सवाल है, यहां प्राथमिकताएं क्या हैं।

स्पष्ट रूप से इस मुद्दे को मौजूदा एपीआई के अपडेट के माध्यम से संबोधित किया जा सकता है, लेकिन, अलग से, मैंने इसके साथ कई बकाया मुद्दों को हल करने के लिए रिएक्टिवफॉर्म मॉड्यूल को बेहतर बनाने का प्रस्ताव बनाया है, जिसमें यह भी शामिल है।

संबोधित किए गए कुछ अन्य मुद्दों में किसी भी संपत्ति पर अपडेट की सदस्यता लेने की क्षमता और एक सेवा के माध्यम से नियंत्रण को एसिंक्रोनस रूप से मान्य करने की क्षमता शामिल है (बजाय asyncValidator )। आप #31963 में अधिक जान सकते हैं। प्रतिक्रिया का स्वागत है!

जैसा कि मैंने पहले वादा किया था , मैंने पुल अनुरोध बनाया। इस पीआर में @ng-stack/forms फीचर का केवल एक हिस्सा है (बिना: सत्यापन, ऑटो डिटेक्ट फॉर्म कंट्रोल और सपोर्ट इनपुट [फाइल])।

अरे, मैं एंगुलर टीम से एक अपडेट साझा करना चाहता था: हम आपको सुनते हैं कि यह एक बड़ा दर्द बिंदु है। हम जल्द ही अधिक मजबूती से टाइप किए गए फॉर्मों पर काम शुरू करेंगे, जिसमें मौजूदा पीआर को देखना और आपकी सभी टिप्पणियों की फिर से समीक्षा करना शामिल होगा। अपने विचार छोड़ने के लिए समय निकालने के लिए आप सभी का धन्यवाद!

ओह!!!!! निकल रहा है!

यह बहुत अच्छी खबर है, एंगुलर टीम, थैंक्स!
जैसे ही कोई रिलीज़ होगी, मैं angular-typesafe-reactive-forms-helper को हटा

हाँ!!!!

मैं बहुत उत्साहित हूँ!! धन्यवाद, कोणीय टीम !!

क्या हम प्रतिक्रिया स्पैम के साथ रुक सकते हैं?
प्रतिक्रियाओं के लिए इमोजी का उपयोग करें, क्योंकि वे https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/ के लिए अभिप्रेत हैं - धन्यवाद।

जैसा कि एंगुलर टीम ने दृढ़ता से टाइप किए गए रिएक्टिव फॉर्म पर काम करने की पुष्टि की है। मैं अपने कार्यान्वयन के अपने कारणों को साझा करना चाहता हूं जो एक चिकनी स्थिर टाइप विकास अनुभव प्राप्त करने के लिए मूल्य प्रकार निकालने के लिए infer प्रकार का

पहला दृष्टिकोण: मूल्य प्रकार के साथ शुरू हुआ

जब मैंने फॉर्मग्रुप डिजाइन करना शुरू किया, मैंने T रूप में सहज ज्ञान युक्त सरल मान प्रकार का उपयोग किया।

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

लेकिन मैंने पाया कि जब मुझे जटिल टेबल फॉर्म आर्किटेक्चर को संभालना होता है, तो एंगुलर एचटीएमएल में टाइप-सेफ बाइंडिंग करना बहुत मुश्किल होता है।

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" />

उपरोक्त कार्यान्वयन के लिए डेवलपर्स को कस्टम टाइप कास्ट करने की आवश्यकता है जो थकाऊ और त्रुटि-प्रवण है। आईएमएचओ, यह दृढ़ता से टाइप किए गए प्रतिक्रियाशील फॉर्म का उपयोग करने का कारण पूरी तरह खो देता है।

दूसरा दृष्टिकोण: कंट्रोल टाइप के साथ शुरू हुआ

एक साधारण मूल्य प्रकार का उपयोग सुचारू रूप से काम नहीं कर रहा है। मैं KeyValueControl का उपयोग करने के लिए एक और विचार आया हूंT और KeyValueControl से मूल्य प्रकार निकालने के लिए infer का उपयोग करेंपुनरावर्ती रूप से।

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" />

लाइव डेमो

लाइव डेमो आईडीई स्क्रीनशॉट

यह एक जटिल रूपों में एक सच्चा स्वत: पूर्ण अनुभव है।

कोणीय टाइप किए गए फॉर्म

मौजूदा रिएक्टिव फॉर्म मॉड्यूल के लिए 100% संगत
https://github.com/gaplo917/angular-typed-forms

टिप्पणियों और सुधारों का स्वागत है। आशा है कि आगामी सशक्त रूप से टाइप किए गए रिएक्टिव फॉर्म टेबल और नेस्टेड सब-फॉर्म जैसे जटिल फॉर्म मॉडल को संभाल सकते हैं।

@IgorMinar , कोणीय कोर टीम , और कोणीय समुदाय के सदस्य ।

यह लंबी टिप्पणी पूरी तरह से दो बयानों पर केंद्रित है जो टिकट लेखक द्वारा " प्रथाओं के खिलाफ " और " दृढ़ता से टाइप किए गए " पर प्रकाश डाला गया है।

मैं दृढ़ता से टाइप किए गए प्रतिक्रियाशील फॉर्म के लिए एक इंटरफ़ेस-आधारित दृष्टिकोण के बजाय सुझाव दूंगा कि हमें कक्षा-आधारित दृष्टिकोण का चयन करना चाहिए, लेकिन उस तरीके से नहीं, जिसका उल्लेख ng-stacks/forms में किया गया है । एंगुलर रिएक्टिव फॉर्म के कोड बेस को बदलने की भी सिफारिश नहीं करेंगे, क्योंकि हम कई तरीकों से कोडबेस को बदले बिना दृढ़ता से टाइप किए गए फॉर्म को प्राप्त कर सकते हैं। मुझे विस्तार से वर्णन करने दें कि इंटरफ़ेस संचालित दृष्टिकोण में मुझे कौन सी उच्च-स्तरीय चुनौतियां दिखाई देती हैं और कक्षा संचालित दृष्टिकोण दूसरों की तुलना में अधिक सहज है और हमें फॉर्मग्रुप ऑब्जेक्ट भी मिल रहा है जो दृढ़ता से टाइप किया गया है। दोनों ही मामलों में, हमारा फॉर्मग्रुप ऑब्जेक्ट स्ट्रॉन्गली टाइप किया गया है, हम क्लास-बेस्ड एप्रोच में टाइपस्क्रिप्ट टाइप की शक्ति नहीं खो रहे हैं।

मेरा सुझाव

जैसा कि हम सभी ओओपी प्रथाओं से परिचित हैं, वर्ग हमें कोड की अधिक लचीलापन और रखरखाव प्रदान करता है। कुछ लाभ जो मैं नीचे बता रहा हूँ:

1. हमारे कोड को अलग करें।
2. वर्तमान दृष्टिकोण के साथ-साथ इंटरफ़ेस-संचालित दृष्टिकोण की तुलना में कम कोड।
3. हम संपत्ति पर कस्टम सज्जाकार का उपयोग कर सकते हैं।
4. कोड पठनीय, रखरखाव योग्य और एक्स्टेंसिबल है।
5. इस दृष्टिकोण के साथ, हमें टेम्पलेट में व्यावसायिक तर्क लिखने की आवश्यकता नहीं है, जैसे हम त्रुटि संदेश दिखाने के लिए कई शर्तों के साथ *ngIf डाल रहे हैं। मेरा मानना ​​है कि टेम्प्लेट व्यावसायिक तर्क लिखने के लिए नहीं हैं।
6. और भी बहुत कुछ...

मुझे उपर्युक्त इंटरफ़ेस कोड को Class में बदलने दें और Class गुणों पर सत्यापन डेकोरेटर लागू करें। यहां हम एकल उत्तरदायित्व सिद्धांत प्रथाओं का पालन ​​कर रहे हैं। नीचे दिए गए कोड पर एक नज़र डालें:

आइए कुछ मामलों पर विचार करें और इसकी तुलना इंटरफ़ेस और क्लास ड्रिवेन स्ट्रॉन्गली-टाइप्ड एप्रोच से करें जो हमें उन दोनों में अंतर को समझने में मदद करता है।

1. एक फॉर्मग्रुप बनाएं
यहाँ हम का एक ही उदाहरण का उपयोग कर रहे FormBuilder और की एक ही विधि group । लेकिन आयात मॉड्यूल का नाम अलग होगा जैसे ReactiveTypedFormsModule बजाय ReactiveFormsModule । आइए एक FormGroup बनाएं:

उपरोक्त कोड के अनुसार, प्रश्न आता है,

क्या वर्तमान दृष्टिकोण ReactiveTypedFormsModule आयात करने के बाद काम करेगा?
हां, यह काम करेगा, ReactiveTypedFormsModule आयात करने के बाद कुछ भी नहीं बदला जाएगा।

आइए जल्दी से अन्य मामलों को देखें और इस पोस्ट को समाप्त करें।

2. फॉर्मकंट्रोल का मान बदलें
setValue विधि को कॉल करने के बजाय, हम सीधे Class संपत्ति पर मान निर्दिष्ट कर सकते हैं। यह स्वचालित रूप से FormControl मान सेट कर देगा।

3. फॉर्मकंट्रोल के मूल्य परिवर्तनों के आधार पर व्यावसायिक तर्क निष्पादित करें
फॉर्मकंट्रोल की सदस्यता लेने के बजाय ValueChanges , टाइपस्क्रिप्ट में setter विधि की शक्ति का उपयोग करें।

4. इनपुट वैल्यू कन्वर्ट करें
हम दृढ़ता से टाइप किए गए पर ध्यान केंद्रित कर रहे हैं लेकिन उन मूल्यों के बारे में जो इनपुट नियंत्रण से आ रहे हैं जैसे तारीख के लिए हमें String प्रारूप में मूल्य मिल रहा है लेकिन हम टीएस कोड में Date प्रारूप की उम्मीद कर रहे हैं, इस समस्या को दूर करने के लिए हम आवश्यकतानुसार मूल्य को परिवर्तित करने के लिए एक निर्देश या विधि बनाते हैं। मैं यहां वर्तमान कोड नहीं दिखाऊंगा क्योंकि यह थोड़ा अनाड़ी है क्योंकि हमें निर्देश बनाना है और ब्ला ब्ला चीजें करना है ... , इसलिए मैं यहां कक्षा संचालित दृष्टिकोण कोड दिखाना चाहता हूं:

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

4. नेस्टेड फॉर्मग्रुप फॉर्मकंट्रोल का मान बदलें
हम नेस्टेड फॉर्मग्रुप ऑब्जेक्ट प्राप्त करने के बजाय संबंधित संपत्ति में सीधे मूल्य निर्दिष्ट कर सकते हैं और SetValue विधि को कॉल कर सकते हैं।

5. नेस्टेड फॉर्मअरे में फॉर्मग्रुप जोड़ना
कहने के लिए और नहीं, नीचे दिए गए कोड 😄 पर एक नज़र डालें।

HTML टेम्पलेट में फॉर्मग्रुप ऑब्जेक्ट का संदर्भ लें

सरल कोड . 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>

स्टैकब्लिट्ज लिंक : रिएक्टिव फॉर्म वर्किंग उदाहरण जोरदार टाइप करें
जीथब पर उदाहरण : जोरदार टाइप किया गया प्रतिक्रियाशील प्रपत्र

@ajyojha , अगर मैं गलत हूं तो मुझे

1. टाइपस्क्रिप्ट प्रकारों के साथ जाने वाला ओवरहेड खराब है।
2. सज्जाकारों की मदद से रनटाइम सत्यापन - यह अच्छा है।
3. यदि सेटर्स/गेटर्स हैं तो आपको setValue() और valueChanges() आवश्यकता क्यों है?

मैं क्या सोचता हूं:

1. टाइपस्क्रिप्ट प्रकार लिखना स्थिर परीक्षण लिखने जैसा है। कोई परीक्षण के बिना एप्लिकेशन बना सकता है क्योंकि उन्हें लगता है कि यह अनावश्यक है, लेकिन यह एक बुरा अभ्यास है।
2. सज्जाकारों की मदद से रनटाइम सत्यापन - यह एक अच्छा विचार हो सकता है, सहमत हैं।
3. setValue() अलावा patchValue() , reset() भी हैं, जो फॉर्म वैल्यू के साथ भी काम करते हैं। केवल setValue() को एक सेटर से बदलने से कोड असंगत हो जाएगा। इसके अलावा, जब हमें प्रत्येक फॉर्म मॉडल संपत्ति के लिए सेटर्स लिखना होता है, तो यह गेटर्स के मामले में बहुत अधिक कोड ओवरहेड के साथ-साथ प्रदर्शन ओवरहेड भी जोड़ देगा। प्रपत्र नियंत्रण गुणों के साथ प्रपत्र मॉडल गुण नाम मिलाना भी मेरी राय में एक बुरा विचार है।

धन्यवाद, @KostyaTretyak मेरी टिप्पणी पर आपकी चिंताओं के लिए, मुझे इसका उत्तर देने में खुशी होगी, कृपया मेरी टिप्पणियों के अनुसार नीचे देखें :)।

1. टाइपस्क्रिप्ट प्रकारों के साथ जाने वाला ओवरहेड खराब है।

केवल आपकी जानकारी के लिए फॉर्मग्रुप ऑब्जेक्ट को जोरदार तरीके से टाइप किया गया है। इंटरफेस अच्छे हैं लेकिन हर क्षेत्र के लिए उपयुक्त नहीं हैं और मैं यह नहीं कह रहा हूं कि टाइपस्क्रिप्ट प्रकार खराब हैं, मुझे नहीं लगता कि कहीं मैंने उल्लेख किया है कि प्रकार खराब हैं। मेरी एकमात्र चिंता इंटरफेस पर है क्योंकि हम इंटरफेस दृष्टिकोण के साथ सॉफ्टवेयर डिजाइन प्रथाओं को खत्म कर रहे हैं या यहां तक ​​​​कि मैं कह सकता हूं कि हम गलत जगह पर इंटरफेस दृष्टिकोण का उपयोग कर रहे हैं और मेरा सुझाया गया दृष्टिकोण क्लास है। जहां तक ​​​​कक्षा दृष्टिकोण के माध्यम से मेरी समझ है, हम टाइपस्क्रिप्ट प्रकारों के लाभ से समझौता नहीं कर रहे हैं जो हमें इंटरफ़ेस में मिलते हैं या यहां तक ​​​​कि मैं कहूंगा कि हमें पठनीयता, मापनीयता और रखरखाव के मामले में इंटरफ़ेस दृष्टिकोण से अधिक मिलता है।

क्या हम सशक्त रूप से टाइप किए गए प्रतिक्रियाशील प्रपत्र के लिए इंटरफ़ेस के सही अभ्यास का उपयोग कर रहे हैं?

मुझे इंटरफ़ेस के संदर्भ में थोड़ा और वर्णन करने दें, जोरदार टाइप किए गए प्रतिक्रियाशील फॉर्म के लिए खराब अभ्यास (मेरे अनुसार) है।

टाइपस्क्रिप्ट प्रकार अच्छे हैं, लेकिन यह सुझाव नहीं दिया जाता है कि हर जगह हमें कुछ भी गड़बड़ करना होगा जो सॉफ्टवेयर प्रथाओं के अनुसार नहीं है जैसे मैंने इंटरफ़ेस के साथ समस्याओं का स्पष्ट रूप से उल्लेख किया है। इंटरफ़ेस पर मेरी हाइलाइट की गई चिंताओं के बारे में सोचने के लिए। मुझे अपना मामला साझा करने दें, मेरे एक एंटरप्राइज़ एप्लिकेशन में जिसमें 6k+ से अधिक घटक शामिल हैं। अगर मैं इंटरफेस दृष्टिकोण के साथ जा रहा हूं तो विकास दल मुझसे बदलाव करने से पहले अच्छे प्रश्न पूछेगा:

• हमें किस इंटरफ़ेस का उपयोग करना है, जहां एक ही इकाई का उपयोग विभिन्न गुणों वाले कई घटकों में किया जाता है। तो क्या हमें अलग इंटरफ़ेस घटक वार बनाने की आवश्यकता है? यदि हाँ, तो दूसरा मामला पढ़ें।
• अगर हम उपरोक्त दृष्टिकोण के साथ जाते हैं तो दृष्टिकोण क्या होगा जहां मुझे एक या कई घटकों में दोनों इंटरफ़ेस गुणों का उपयोग करना होगा। इस चिंता के समाधान के लिए, मैं एक और इंटरफ़ेस बना सकता हूँ और उसका विस्तार कर सकता हूँ। क्या केवल स्ट्रांगली टाइप रिएक्टिव फॉर्म के शेक के लिए अधिक से अधिक फाइलें बनाना अच्छा है? रखरखाव के बारे में क्या?, मेरे पास जवाब नहीं है, सिवाय इसके कि कोणीय टीम यह समाधान प्रदान कर रही है इसलिए यह अच्छा है :) (यदि कोणीय टीम इंटरफ़ेस दृष्टिकोण का चयन करेगी)।
• अगर हम ए + बी दृष्टिकोण के साथ जाते हैं तो मेरे कुछ घटकों में कुछ गुणों की आवश्यकता होती है, तो सभी नहीं? मेरी विकास टीम को देने के लिए मेरे पास तीन समाधान हैं।
  
  
  
  • एक नया इंटरफ़ेस बनाएं और नए बनाए गए इंटरफ़ेस में आवश्यक गुणों को कॉपी/पेस्ट करें। सॉफ्टवेयर की दुनिया में यह सबसे गंदा तरीका है। यह बहुत सारी समस्याएं पैदा करता है जब सर्वर की तरफ किसी एक संपत्ति को बदल दिया जाएगा तो संपत्ति के नाम को बदलने के लिए कितने इंटरफेस में क्षेत्रों को समान रूप से ट्रैक करना मुश्किल है।
  
  
  • संपत्ति को शून्य करने योग्य सेट करें। अगर मैं संपत्ति को शून्य करने योग्य परिभाषित कर रहा हूं तो मुझे 'बी' दृष्टिकोण का पालन क्यों करना है? दोबारा मेरे पास कोई जवाब नहीं है :( मेरी विकास टीम देने के लिए।
  
  
  • दूसरा इंटरफ़ेस न बनाएं, 'आंशिक' उपयोगिता प्रकार का उपयोग करें, और प्रत्येक संपत्ति को वैकल्पिक बनाएं। ऐसा करने से हम इंटरफ़ेस का वास्तविक लाभ खो रहे हैं। यह प्रथाओं के खिलाफ भी है। अगर मुझे इसका पालन करना है तो मुझे 'ए' दृष्टिकोण का पालन क्यों करना है, फिर से कोई जवाब नहीं :)।
  
  
  • अगर मैं प्रत्येक/कुछ गुणों को निरर्थक बना रहा हूं तो कोड पठनीयता के बारे में क्या है और मैं कैसे तय कर सकता हूं कि सर्वर को मूल्य पारित करने के लिए कितनी संपत्तियों की आवश्यकता है। फिर मुझे संबंधित घटक की जांच करनी होगी और एक झलक प्राप्त करनी होगी। प्रमुख कोड पठनीयता चिंता।
  
  

अब बस उपरोक्त मामलों पर एक बड़े परिप्रेक्ष्य पर विचार करने के लिए और टाइपस्क्रिप्ट प्रकारों के साथ इंटरफेस ऑन रिएक्टिव फॉर्म्स के साथ मजबूत टाइप करने के लिए तुलना करें। मेरा मानना ​​​​है कि हर अच्छा दृष्टिकोण विकास के समय को बचाएगा और इस दृष्टिकोण में क्षमा करें, मुझे सॉफ़्टवेयर डिज़ाइन सिद्धांत और प्रथाओं के अनुसार कोई लाभ नहीं दिख रहा है।

1. सज्जाकारों की मदद से रनटाइम सत्यापन - यह अच्छा है।

मैं " इट्स गुड " पर आपकी टिप्पणी से सहमत हूं, डेकोरेटर दृष्टिकोण जिसे हम इंटरफ़ेस दृष्टिकोण में प्राप्त नहीं कर सकते हैं। मेरा मानना ​​​​है कि यह टाइपस्क्रिप्ट की सबसे शक्तिशाली विशेषता है, फिर हम इसका उपयोग रिएक्टिव फॉर्म एप्रोच में क्यों नहीं कर सकते हैं और विकास टीम को उनके ऑब्जेक्ट गुणों का पूर्ण नियंत्रण दे सकते हैं।

1. यदि सेटर्स हैं तो आपको setValue() की आवश्यकता क्यों है?

जहां मैंने कहा है कि मुझे 'सेटवैल्यू ()' की आवश्यकता है? मुझे सेटवैल्यू की आवश्यकता नहीं है और मैंने उस उदाहरण में नहीं दिखाया है जहां मैं कक्षा संचालित दृष्टिकोण में सेटवैल्यू विधि को कॉल कर रहा हूं। यदि मैं गलत हूं तो मुझे बताएं।

1. टाइपस्क्रिप्ट प्रकार लिखना स्थिर परीक्षण लिखने जैसा है। कोई परीक्षण के बिना एप्लिकेशन बना सकता है क्योंकि उन्हें लगता है कि यह अनावश्यक है, लेकिन यह एक बुरा अभ्यास है।

मैं यह नहीं कह रहा हूं कि टाइपस्क्रिप्ट प्रकार स्थिर परीक्षण लिखने जैसा है। लेकिन मैं प्रतिक्रियाशील रूप के आधार वर्गों में प्रतिबद्ध परिवर्तनों से सहमत नहीं हूं, मेरा मानना ​​​​है कि हम वर्ग परिभाषा को छूए बिना एक ही चीज़ प्राप्त कर सकते हैं। यहां, हम इंटरफ़ेस की वास्तविक शक्ति का उपयोग कर सकते हैं जिसका उपयोग हम अब तक कमिट के अनुसार नहीं कर रहे हैं, क्या यह एक अच्छा अभ्यास है कि तर्क इतने लंबे समय तक चल रहा है और हम 'के डिफ़ॉल्ट मान को सेट करके सामान्य प्रकार जोड़ रहे हैं। कोई'?
मुझे लगता है कि हम प्रतिक्रियाशील रूप के आधार वर्गों को छुए बिना एक ही चीज़ प्राप्त कर सकते हैं। मुझे नहीं पता कि हम बेस क्लास की परिभाषा बदलने और कल्पना को बदलने के बजाय इसमें इंटरफेस का लाभ क्यों नहीं उठा रहे हैं।

1. सज्जाकारों की मदद से रनटाइम सत्यापन - यह एक अच्छा विचार हो सकता है, सहमत हैं।

यह जानकर अच्छा लगा कि हम दोनों इस पर एक ही पृष्ठ हैं :)।

1. सेटवैल्यू () के अलावा पैचवैल्यू (), रीसेट () भी हैं, जो फॉर्म वैल्यू के साथ भी काम करते हैं। केवल setValue() को एक सेटर से बदलने से कोड असंगत हो जाएगा। इसके अलावा, जब हमें प्रत्येक फॉर्म मॉडल संपत्ति के लिए सेटर्स लिखना होता है, तो यह बहुत अधिक कोड ओवरहेड के साथ-साथ प्रदर्शन ओवरहेड भी जोड़ देगा। प्रपत्र नियंत्रण गुणों के साथ प्रपत्र मॉडल गुण नाम मिलाना भी मेरी राय में एक बुरा विचार है।

मुझे उपरोक्त बिंदु को तीन खंडों में कॉलिंग विधि, सेटर प्रदर्शन ओवरहेड, और मिश्रण फॉर्म मॉडल गुणों में वर्णित करने दें।

कॉल करने का तरीका: जैसा कि अपेक्षित था, इस पोस्ट को लिखते समय मैं सोच रहा था कि कोई मुझे 'पैचवैल्यू' या 'रीसेट' पद्धति का उपयोग करने का सुझाव दे सकता है। फिर से मैं वास्तविक दुनिया के मामले में कहना चाहूंगा कि ज्यादातर विकास टीम पैचवैल्यू या अन्य तरीकों के बजाय 'सेटवैल्यू' पद्धति का उपयोग कर रही है (यह कोणीय अनुप्रयोग कोड समीक्षा और स्टैक ओवरफ्लो पोस्ट सेटवैल्यू बनाम पैचवैल्यू के अनुसार मेरा अनुभव है)। मेरा ध्यान केवल मान निर्दिष्ट करने के लिए विधि को बुला रहा है, चाहे हम किसी भी विधि के लिए कॉल कर रहे हों।

सेटर प्रदर्शन : मैं सेटर्स के बयान से सहमत हूं कि एक प्रदर्शन ओवरहेड बनाता है। यदि ऐसा है तो मैं कहूंगा कि हमें पहले कोणीय परियोजना में ठीक करना होगा क्योंकि प्रतिक्रियाशील रूप को बाध्य करने के लिए, कोणीय फ्रेमवर्क कंट्रोल वैल्यू एक्सेसर क्लास और कई अन्य निर्देशों में सेटर विधि का उपयोग कर रहा है और यह उपयोग किए बिना एक प्रदर्शन ओवरहेड बनाता है कक्षा दृष्टिकोण। एक और बात एक ही दृष्टिकोण हम @Input डेकोरेटर के साथ कई घटकों में भी उपयोग कर रहे हैं, हमें वैकल्पिक या कोणीय टीम को इस तरह के प्रदर्शन के मुद्दे को दूर करने के लिए एक अलग समाधान (मेरा मानना ​​​​है) प्रदान करना होगा। इसलिए, मुझे नहीं लगता कि यह कोई बड़ी चिंता है। अब प्रदर्शन की चिंता पर आ रहे हैं, कृपया मौजूदा दृष्टिकोण और सेटर विधि दृष्टिकोण के साथ तुलना करें (यह वैकल्पिक है, विकास टीम चुन सकती है यदि वे एंगुलर में ChangeDetectionStrategy की तरह ही चाहें। कृपया चुनने के लिए rxweb प्रलेखन साइट पर उदाहरण देखें। यह मामला। जज करें कि जब हम मूल्य परिवर्तन की सदस्यता लेते हैं तो कितने फ़ंक्शन कॉल कर रहे हैं, फिर मान सेट करने या सीधे सेटर विधि को कॉल करने के बाद। मेरा मानना ​​​​है कि यह कम कोड निष्पादन के मामले में मूल्य परिवर्तन, कम आकार के निर्माण की तुलना में अधिक सहज है पैकेज, कोड पठनीयता और कई अन्य अच्छी चीजें।

गुणों का मिश्रण : तो आपकी क्या राय है, क्या आप सर्वर द्वारा लौटाए गए संपत्ति के नाम से भिन्न फॉर्मकंट्रोल संपत्ति नाम निर्दिष्ट कर रहे हैं। यदि हां, तो मैं कहूंगा कि यह कोड में एक बड़ी समस्या है क्योंकि हर बार मुझे सर्वर पर पोस्ट करने से पहले संपत्ति का नाम बदलना पड़ता है, क्षमा करें, लेकिन मैं पूरे एप्लिकेशन में पसंद नहीं करूंगा। अगर मैं अपने आवेदन फॉर्म के लिए आपकी अच्छी राय पर विचार करता हूं जिसमें औसत 40+ फ़ील्ड हैं तो मुझे प्रत्येक संपत्ति मूल्य को मैन्युअल रूप से सेट करना होगा, केवल मूल्य और उत्पाद निर्माण आकार को निर्दिष्ट करने के शेक के लिए घटक में कोड के बारे में सोचने के लिए। क्या यह वर्ग दृष्टिकोण से बेहतर राय है?
अब प्रस्तावित समाधान पर आते हैं, हम दो चीजों को एक में नहीं मिला रहे हैं। फॉर्मकंट्रोल गुण अलग हैं और वर्ग गुण संबंधित डेटा प्रकार से भिन्न हैं। यदि आप संपत्ति का नाम बदलना चाहते हैं जैसे फॉर्मकंट्रोल संपत्ति का नाम डेटा संपत्ति से अलग है, तो आप कर सकते हैं, कृपया आरएक्सवेब रिएक्टिव फॉर्म पैकेज दस्तावेज देखें। तो कोई समस्या नहीं है क्योंकि आपके खराब होने की भावना (प्रॉपर्टी के नाम को फॉर्म-कंट्रोल नामों के साथ मिलाकर) प्रस्तावित दृष्टिकोण में एक समाधान है।

मुझे आशा है कि मैंने आपकी सभी चिंताओं का उत्तर दिया है, यदि आप इस पर कोई अन्य चिंताएं हैं तो बेझिझक साझा करें :)।

जैसा कि मैंने अपनी पिछली टिप्पणी में कहा था कि रिएक्टिव फॉर्म के आधार वर्गों में बदलाव की कोई आवश्यकता नहीं है क्योंकि हम इंटरफ़ेस पृथक्करण सिद्धांत प्रथाओं की शक्ति का उपयोग करके समान चीजें प्राप्त कर सकते हैं। यहां @rxweb/types के पैकेज के साथ एंड-टू-एंड रिएक्टिव फॉर्म सॉल्यूशन दिया गया है। यह इंटरफेस के साथ-साथ कक्षा दृष्टिकोण के साथ अच्छी तरह से काम करता है :)।

कार्यान्वयन के बाद कोड कैसा दिखता है?

स्टैकब्लिट्ज: ओपन
जीथब : इंटरफेस ड्रिवेन स्ट्रॉन्गली-टाइप्ड रिएक्टिव फॉर्म उदाहरण

किसी के पास कोई सुझाव है तो उसे बेझिझक साझा करें।

इसलिए, एंगुलर नाउ अवेलेबल का संस्करण 10 , यह एक प्रमुख रिलीज है और जाहिरा तौर पर प्रतिक्रियाशील रूपों को एंगुलर के कम से कम संस्करण 11 तक दृढ़ता से टाइप नहीं किया जाएगा। इसलिए, हमें इस सुविधा को लागू करने के लिए कम से कम गिरावट तक इंतजार करना होगा।

मेरे पास यहां देखे गए अधिकांश सुझावों/पीआर में फॉर्म मॉडल के निर्माण के तरीके के बारे में एक प्रश्न (या एक प्रस्ताव?) है।

प्रतिक्रियाशील प्रपत्र प्रकार को सुरक्षित बनाने का प्रयास करने वाले अधिकांश पुस्तकालयों और पीआर को देखते समय, आप देख सकते हैं कि वे एक ऐसा मॉडल बनाते हैं जो इस तरह दिखता है:

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'),
  })
})

तो, सरल शब्दों में: "यदि यह एक वस्तु है, तो इसके लिए एक फॉर्मग्रुप बनाएं। यदि यह एक सरणी है, तो एक फॉर्मएरे बनाएं। और यदि यह एक आदिम मान है, तो फॉर्मकंट्रोल बनाएं।"

लेकिन, एक समस्या है: अब आप FormControls में ऑब्जेक्ट का उपयोग नहीं कर सकते।

अब तक मैंने जो समाधान देखे हैं: कुछ पुस्तकालय इसका समर्थन नहीं करते हैं। और कुछ पुस्तकालय एक संकेत बनाने के लिए किसी प्रकार के "हैक" का उपयोग करते हैं कि आप वास्तव में फॉर्म ग्रुप के बजाय फॉर्मकंट्रोल का उपयोग करना चाहते हैं।

मेरा प्रश्न/प्रस्ताव: फॉर्म मॉडल को स्पष्ट रूप से परिभाषित करने के खिलाफ क्या बोलेंगे?

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'),
  })
})

इसका बड़ा फायदा यह है कि अब आप ऑब्जेक्ट को फॉर्मकंट्रोल में डाल सकते हैं। और ऐसा करने के लिए किसी भी प्रकार के "हैक" की आवश्यकता नहीं है :)

मैंने इसके लिए एक कोडसैंडबॉक्स बनाया है, ताकि आप इसे स्वयं आजमा सकें: https://codesandbox.io/s/falling-grass-k4u50?file=/src/app/app.component.ts

@MBuchalik , हाँ, यह पहला स्पष्ट निर्णय है जो आपके दिमाग में आता है जब आप "मजबूत टाइप किए गए फॉर्म" पर काम करना शुरू करते हैं। मैंने इसके साथ शुरुआत भी की, लेकिन इसका एक महत्वपूर्ण नुकसान है - दो मॉडल बनाने की आवश्यकता: एक फॉर्म नियंत्रण के लिए, दूसरा - फॉर्म वैल्यू के लिए।

दूसरी ओर, जहां तक ​​मैं समझता हूं, यह समाधान हमें बिना किसी बाधा के "मजबूत टाइप किए गए रूपों" को लागू करने की अनुमति देगा, और हमें एंगुलर के अगले प्रमुख संस्करण के जारी होने की प्रतीक्षा नहीं करनी होगी। यहां यह आकलन करने के लिए इस तरह के समाधान के साथ व्यवहार में काम करना आवश्यक है कि क्या इसमें दो मॉडल बनाने की आवश्यकता से अधिक महत्वपूर्ण कमियां हैं।

@MBuchalik मैंने आपके साथ वही राय साझा की है और पीआर को एक ही सवाल उठाया है और कोणीय योगदानकर्ताओं में से एक ( @KostyaTretyak ) ने उत्तर दिया है।

आप पीआर में चर्चा पर एक नज़र डाल सकते हैं:
https://github.com/angular/angular/pull/37389#discussion_r438543624

टीएलडीआर;

यहां कुछ समस्याएं हैं:
यदि हम आपके दृष्टिकोण का अनुसरण करते हैं, तो हमें दो अलग-अलग मॉडल बनाने होंगे - प्रपत्र नियंत्रणों के लिए और प्रपत्र मानों के लिए।
प्रपत्र नियंत्रण के मॉडल को पढ़ना कठिन है।

और मैंने इस विचार को आधे साल पहले fullTemplateTypeCheck सक्षम के साथ)

मैंने इस सूत्र में पिछली टिप्पणी में "मैं इस तरह क्यों जाता हूं" साझा किया है:
https://github.com/angular/angular/issues/13721#issuecomment -643214540

कोडसैनबॉक्स डेमो: https://codesandbox.io/s/github/gaplo917/angular-typed-form-codesandbox/tree/master/?fontsize=14&hidenavigation=1&theme=dark

आपकी अंतर्दृष्टि @KostyaTretyak और @ gaplo917 के लिए धन्यवाद! मैं

अगर मैंने इसे सही ढंग से समझा, तो हम इसे इस प्रकार संक्षेप में प्रस्तुत कर सकते हैं।

यदि हम केवल एक एकल मॉडल का उपयोग करना चाहते हैं, तो @KostyaTretyak द्वारा प्रदान किए गए समाधान जैसे समाधान का उपयोग किया जा सकता है। हालांकि नकारात्मक पक्ष यह है कि अब हम अब फॉर्मकंट्रोल में वस्तुओं का उपयोग नहीं कर सकते हैं। (मुझे पता है कि एक "हैक" है जो इसकी अनुमति देगा। लेकिन फिर हमारा मॉडल फिर से "क्लीन" नहीं है, इसलिए हमें एक बार फिर 2 मॉडल की आवश्यकता होगी।)

यदि हम फॉर्मकंट्रोल में वस्तुओं का उपयोग करने में सक्षम होना चाहते हैं, तो संभवतः (!) एक दृष्टिकोण का उपयोग करने के आसपास कोई रास्ता नहीं है I (या @ gaplo917) सचित्र। नकारात्मक पक्ष यह है कि आपको मूल रूप से 2 मॉडल की आवश्यकता होती है। या फॉर्म वैल्यू मॉडल को "निकालने" के लिए कम से कम कुछ सहायक प्रकारों का उपयोग करें।

तो, अब हमें केवल यह सोचने की ज़रूरत है कि क्या FormControls में ऑब्जेक्ट संभव होना चाहिए या नहीं। यह केवल इस प्रश्न का उत्तर देगा कि दोनों में से कौन सा दृष्टिकोण चुनना है। या क्या मैं कुछ न कुछ भूल रहा हूं?

आपकी अंतर्दृष्टि @KostyaTretyak और @ gaplo917 के लिए धन्यवाद! मैं

अगर मैंने इसे सही ढंग से समझा, तो हम इसे इस प्रकार संक्षेप में प्रस्तुत कर सकते हैं।

यदि हम केवल एक एकल मॉडल का उपयोग करना चाहते हैं, तो @KostyaTretyak द्वारा प्रदान किए गए समाधान जैसे समाधान का उपयोग किया जा सकता है। हालांकि नकारात्मक पक्ष यह है कि अब हम अब फॉर्मकंट्रोल में वस्तुओं का उपयोग नहीं कर सकते हैं। (मुझे पता है कि एक "हैक" है जो इसकी अनुमति देगा। लेकिन फिर हमारा मॉडल फिर से "क्लीन" नहीं है, इसलिए हमें एक बार फिर 2 मॉडल की आवश्यकता होगी।)

यदि हम फॉर्मकंट्रोल में वस्तुओं का उपयोग करने में सक्षम होना चाहते हैं, तो संभवतः (!) एक दृष्टिकोण का उपयोग करने के आसपास कोई रास्ता नहीं है I (या @ gaplo917) सचित्र। नकारात्मक पक्ष यह है कि आपको मूल रूप से 2 मॉडल की आवश्यकता होती है। या फॉर्म वैल्यू मॉडल को "निकालने" के लिए कम से कम कुछ सहायक प्रकारों का उपयोग करें।

तो, अब हमें केवल यह सोचने की ज़रूरत है कि क्या FormControls में ऑब्जेक्ट संभव होना चाहिए या नहीं। यह केवल इस प्रश्न का उत्तर देगा कि दोनों में से कौन सा दृष्टिकोण चुनना है। या क्या मैं कुछ न कुछ भूल रहा हूं?

@MBuchalik मेरी राय में, यदि आप टाइपस्क्रिप्ट कंपाइलर पर भरोसा करते हैं और "टाइप इंट्रेंस" फीचर पर बहुत अधिक भरोसा करते हैं, तो आपको 2 मॉडल रखने की आवश्यकता नहीं है। हमारी आंतरिक प्रणाली में 60+ रूप हैं, उनमें से कुछ 3 गहराई स्तर FormArray-FormGroup-FormArray साथ बहुत जटिल हैं और हमें मूल्य प्रकार के लिए स्पष्ट मॉडल की भी आवश्यकता नहीं है।

खेलने के लिए केवल 2 प्रकार के डेटा मॉडल हैं:

• एपीआई डेटा अनुरोध/प्रतिक्रिया मॉडल
• फॉर्मकंट्रोल मॉडल

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)
   }
}

पीएस यह एक अनुमानित डेटा प्रवाह वास्तुकला है जिसे हम टाइपस्क्रिप्ट में सुरक्षित रूप से प्रोग्रामिंग का आनंद ले सकते हैं

यदि हम केवल एक एकल मॉडल का उपयोग करना चाहते हैं, तो @KostyaTretyak द्वारा प्रदान किए गए समाधान जैसे समाधान का उपयोग किया जा सकता है। हालांकि नकारात्मक पक्ष यह है कि अब हम अब फॉर्मकंट्रोल में वस्तुओं का उपयोग नहीं कर सकते हैं। (मुझे पता है कि एक "हैक" है जो इसकी अनुमति देगा। लेकिन फिर हमारा मॉडल फिर से "क्लीन" नहीं है, इसलिए हमें एक बार फिर 2 मॉडल की आवश्यकता होगी।)

यहां यह अनुमान लगाना अभी भी आवश्यक है कि हमें कितनी बार किसी वस्तु का उपयोग करने की आवश्यकता है FormControl । मुझे लगता है कि इसका अनुमान कहीं न कहीं 5-30% लगाया जा सकता है। यही है, अगर हम एक मॉडल के साथ समाधान का उपयोग करते हैं, तो हम FormControl का उपयोग करने के 70-95% मामलों को कवर कर सकते हैं। बाकी के लिए - बस टाइपस्क्रिप्ट को एक अतिरिक्त प्रकार के रूप में संकेत दें (देखें Control<T> , इसे "दूसरा मॉडल" कहना सही नहीं है):

interface FormModel {
  date: Control<Date>;
}

क्या Control<T> प्रकार को हैक कहा जा सकता है? - हाँ, यह शायद एक हैक है, लेकिन एक मोटा हैक नहीं है। मैं ऐसे किसी भी मामले के बारे में नहीं जानता जहां यह प्रकार इरादे के अनुसार काम नहीं करता है, या इसके दुष्प्रभाव हैं।

ओह, मुझे Control<T> के साइड इफेक्ट याद आ गए जब हमें फॉर्म वैल्यू मॉडल के लिए बाहरी लाइब्रेरी का उपयोग करने की आवश्यकता होती है। ऐसे मामलों में, दो मॉडलों की वास्तव में आवश्यकता होती है:

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> प्रकार के साथ एक महत्वपूर्ण मुद्दा अब ज्ञात हो गया है। है यही कारण है कि, मैं भी लागू करने के लिए कोशिश नहीं करेंगे Control<T> , कोणीय के लिए भविष्य पुल अनुरोध में के रूप में मैं पहले की योजना बनाई।

@ArielGueta के लिए धन्यवाद, Control<T> प्रकार के साथ एक महत्वपूर्ण मुद्दा अब ज्ञात हो गया है। है यही कारण है कि, मैं भी लागू करने के लिए कोशिश नहीं करेंगे Control<T> , कोणीय के लिए भविष्य पुल अनुरोध में के रूप में मैं पहले की योजना बनाई।

@KostyaTretyak यह सच नहीं है। महत्वपूर्ण समस्या केवल यह दर्शाती है कि आपका "कंट्रोल टाइप" कार्यान्वयन गलत है।

एक पूर्ण "नियंत्रण प्रकार" कार्यान्वयन में कोई समस्या नहीं है।

लाइव डेमो: https://codesandbox.io/s/lucid-bassi-ceo6t?file=/src/app/demo/forms/type -test.ts

यानी मैं Control को लागू करने की कोशिश भी नहीं करूंगाभविष्य में कोणीय के लिए अनुरोध खींचें, जैसा कि मैंने पहले योजना बनाई थी।

ठीक है, तो इसका मतलब है कि आपका पीआर (और लगातार वाले) कभी भी फॉर्मकंट्रोल में ऑब्जेक्ट्स का समर्थन नहीं करेंगे?

@MBuchalik , इस समय (कोणीय 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 , मैंने आपके समाधानों की कोशिश की है, और अपने समान समाधान को लागू करने का प्रयास किया है, लेकिन वे सभी पूरी तरह से काम नहीं करते हैं। यह समाधान फ़ॉर्म मॉडल मानों को पुनरावर्ती रूप से निकालने के लिए प्रकारों का एक सेट भी प्रदान करता है। ओवरहेड और ब्रेकिंग परिवर्तन बहुत महत्वपूर्ण हैं, पीआर ड्राफ्ट देखें।

मुझे दृढ़ता से संदेह है कि फिलहाल इन समाधानों को एंगुलर में लागू करने का प्रस्ताव दिया जाना चाहिए। यानी, अभी के लिए हमें जेनरिक का उपयोग केवल फॉर्म वैल्यू के लिए करना होगा, न कि फॉर्म कंट्रोल टाइप्स के लिए।

लेकिन वे सभी पूरी तरह से काम नहीं करते हैं

मैंने अपने दृष्टांत पर केवल कुछ घंटे बिताए हैं, इसलिए मुझे उम्मीद नहीं थी कि यह सही होगा;) क्या आप उन चीजों पर उदाहरण दे सकते हैं जो अच्छी तरह से काम नहीं करती हैं? (खासतौर पर ऐसे सामान पर, जो आपके दृष्टिकोण से आसानी से तय नहीं किया जा सकता है?)

बीटीडब्ल्यू, पिछली संगतता के बारे में एक सुझाव: मेरे दृष्टिकोण से, कार्यान्वयन को पूरी तरह से पीछे की ओर संगत बनाना अपेक्षाकृत कठिन है। इस वजह से, हम शायद निम्न कार्य कर सकते हैं: हम फॉर्मकंट्रोल, फॉर्मग्रुप और फॉर्मअरे कक्षाओं को बिल्कुल भी नहीं बदलते हैं। इसके बजाय, हम नए बनाते हैं जो उनसे प्राप्त होते हैं (शायद उन्हें StrictFormControl<T> और StrictFormGroup<T> या जो भी आपको पसंद हो)। ये तब हैं जब हम टाइप को सुरक्षित बनाते हैं। लाभ: हम 100% सुनिश्चित हैं कि कोई ब्रेकिंग परिवर्तन नहीं किया गया है। :)

मेरे चित्रण पर कुछ घंटे, इसलिए मुझे उम्मीद नहीं थी कि यह सही होगा;)

मैंने इस समाधान के साथ कुछ दिनों तक काम किया, और मैं देखता हूं कि रूपों के साथ काम करना कितना मुश्किल होगा।

1. सबसे पहले, महत्वपूर्ण ओवरहेड और दो मॉडल होने की आवश्यकता है।
2. दूसरे, यह समाधान विश्वसनीयता के मामले में Control<T> प्रकार के साथ मेरे समाधान से बेहतर नहीं है, क्योंकि उसी तरह फॉर्म मॉडल के मूल्य को पुन: निकालने के लिए आवश्यक है।
3. नेस्टेड प्रपत्र नियंत्रण के साथ कार्य करें। यदि हमारे पास निम्न फॉर्म मॉडल है:

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

और अगर हमें formGroup.controls.one.value , तो टाइपस्क्रिप्ट सशर्त प्रकार के साथ संकेत प्रदान करता है, न कि {two: string} प्रकार के साथ (जैसा होना चाहिए)। तो आईडीई से पढ़ने के लिए कठिन मूल्य।

और अगर हमें formGroup.controls.one.value मिलता है, तो टाइपस्क्रिप्ट सशर्त प्रकार के साथ संकेत प्रदान करता है, न कि {दो: स्ट्रिंग} प्रकार (जैसा होना चाहिए) के साथ। तो आईडीई से पढ़ने के लिए कठिन मूल्य।

ठीक है तो बस यह सुनिश्चित करने के लिए कि मैं सब कुछ सही ढंग से समझ गया हूं। यदि आप मेरे कार्यान्वयन का उपयोग करते हैं और निम्नलिखित लिखते हैं:

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 तलाश करता हूं तो ऐसा लगता है:

तो आप कहते हैं कि, इस उदाहरण में, "दो" वैकल्पिक नहीं होना चाहिए? मुझे लगता है कि फॉर्म वैल्यू टाइप करने का यह सही तरीका नहीं है। प्रपत्र मान में केवल अक्षम फ़ील्ड शामिल नहीं हैं। तो, मेरे दृष्टिकोण से, यह एक पुनरावर्ती आंशिक होना चाहिए। आप संकलन समय पर नहीं जान सकते कि कौन से फ़ील्ड अक्षम किए जाएंगे और कौन से नहीं।

तो आप कहते हैं कि, इस उदाहरण में, "दो" वैकल्पिक नहीं होना चाहिए?

क्या? नहीं।

आपके समाधान का मेरा परीक्षण:

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

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

value पर माउस होवर करने के बाद मैं codesandbox पर क्या देखता हूं:

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

यहां PartialFormGroupValue सशर्त प्रकार PartialFormValue को संदर्भित करता है।

आह, ठीक है, मुझे लगता है कि मुझे मिल गया। तो आपका मतलब है कि टाइप पढ़ना मुश्किल है, है ना? मैंने मूल रूप से सोचा था कि आप किसी बग या उस तरह के कुछ के बारे में बात कर रहे थे।

ठीक है, एक बार टाइप करना जारी रखने के बाद, अधिकांश आईडीई अभी भी उपलब्ध गुणों के लिए सुझाव प्रस्तुत करेंगे। इसलिए मुझे वास्तव में यहां कोई बड़ी समस्या नहीं दिख रही है। (बेशक, यह पढ़ना बेहतर होगा अगर यह सिर्फ {two?: string} । लेकिन मुझे नहीं लगता कि यह बहुत महत्वपूर्ण है। यह कम से कम मेरी राय है।)

यदि आपने अपना Control<T> , तो आप इसे sth किए बिना फॉर्म वैल्यू के टाइपिंग से कैसे हटाएंगे जैसे मैंने किया था? और आप एक सहायक प्रकार का उपयोग किए बिना फॉर्म वैल्यू को रिकर्सिव आंशिक कैसे बनायेंगे?

यदि आपने अपना नियंत्रण लागू किया है, तो आप इसे sth किए बिना फॉर्म वैल्यू के टाइपिंग से कैसे हटाएंगे जैसे मैंने किया था? और आप एक सहायक प्रकार का उपयोग किए बिना फॉर्म वैल्यू को रिकर्सिव आंशिक कैसे बनायेंगे?

इस मामले में, मेरा समाधान बेहतर नहीं है:

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

मैंने यह उदाहरण इसलिए दिया क्योंकि आपने इसके लिए कहा था:

क्या आप उन चीजों पर उदाहरण दे सकते हैं जो अच्छी तरह से काम नहीं करती हैं? (खासतौर पर ऐसे सामान पर, जो आपके दृष्टिकोण से आसानी से तय नहीं किया जा सकता है?)

वैसे, मैंने Control<T> साथ गंभीर समस्या को ठीक कर दिया है।

कोणीय 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 } रूप में अपने प्रकार को सही ढंग से दिखाएगा, और अगर फॉर्म नेस्टेड फॉर्मग्रुप या सरणी के साथ अधिक जटिल था तो सही ढंग से एकत्रित होगा।

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 s पर टाइपिंग शामिल करने के लिए बढ़ाया है और सब कुछ समेटने के लिए एक लेख बनाया है:

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

इसे अब भविष्य के विकास के रोडमैप पर चिह्नित किया गया है: https://angular.io/guide/roadmap#better -developer-ergonomics-with-strict-typing-for-angularforms

@pauldraper क्या आप बता सकते हैं कि ~ 2 महीने पहले के रोडमैप की तुलना में क्या बदल गया है? केवल एक ही परिवर्तन जो मैं देख रहा हूँ वह है शीर्षक की शब्दावली। लेकिन यह अभी भी "भविष्य" खंड में है। ठीक वैसे ही जैसे 2 महीने पहले था।

@MBuchalik शायद 2 महीने से है।