Yes! When we finally do this, it will be a breaking change. We'll ship it with a migration schematic to keep code that relies on the previous behavior working.

I don't know, but how about adding a new method instead of changing the reset behaviour? something likeformName.resetToInitialValue() (or a better name). So the reset behaviour stays the same and this additional feature gets added?

I really doubt that some schematic can deal with cases when reset() in one library, and code creating the form is in another. The new method is a much better idea.

how about adding a new method instead of changing the reset behaviour

@asincole The problem is that your form wouldn't be type-safe anymore. Consider the following:

constdog=newFormControl<string>('spot');dot.reset();console.log(dog.value);// null! This violates the type of `string`!

when reset() in one library, and code creating the form is in another.

@e-oz Indeed, this would be quite tricky to migrate. We'll need to think more about the migration story here.

I don't know, but how about adding a new method instead of changing the reset behaviour? something like formName.resetToInitialValue() (or a better name). So the reset behaviour stays the same and this additional feature gets added?

This is why (3) is an open question - we want to understand if the existing behavior around resetting tonull is valuable enough to keep around, or if we should pursue removing it entirely.

I really doubt that some schematic can deal with cases when reset() in one library, and code creating the form is in another. The new method is a much better idea.

We would probably make theinitialValueIsDefault flag mandatory, and a migration would add it where it's missing. Then in a future release, we could flip the default of that flag, and eventually deprecate and remove it.

I think it would be "nicer" to have this as the default behavior (reset to default value) and have migrations to add initialValueAsDefault: false to the consumers' code.

I agree, it would definitely be nicer.

One of the things we consider when making these kinds of changes is the example code that exists in the wild. The problem with changing the default directly like this (even if we could make existing app code continue to work with a migration) is that example code in blogs, tutorials, etc would suddenly have different semantics, making them obsolete or at least extremely confusing.

So we usually prefer to make such changes slowly, by first introducing a flag and then flipping the default as a separate step.

This makes total sense Alex. I didn't account for existing tutorials out there. Thanks!

It's a bit confusing to allow aninitialValueIsDefault property on aFormGroup. Consider the following pedantic example:

constnullableDog=newFormControl<string|null>=('spot');constnonNullableCat=newFormControl<string>=('tabby',{initialValueIsDefault:true});constanimals=newFormGroup({cat:nonNullableCat,dog:nullableDog,},/* hypothetical property on a group */{initialValueIsDefault:true});

What happens here? The twoFormControls have already been constructed, so it's too late to change their types, and the types conflict with each other anyway.

I agree this could be a pretty verbose to add to all yourFormControls. Would it help if we provided a schematic to do it automatically? Or perhaps there is a simpler API possibility I haven't thought of.

They return non-null types by default and we architected our code based around not having nulls on our models.

@ng-neat/reactive-forms does not address thereset() problem -reset() on aFormControl<string> will set it to anull value in spite of its strongly typed nature. A similar problem exists withFormGroup.value in that package - its.value type doesn't reflect that individual keys may not be present if the underlying controls are disabled.

I agree that creating lots ofFormControls with options set is challenging. A helper method could make this simpler:

functionmakeFormControl<T>(value:T):FormControl<T>{returnnewFormControl(value,{initialValueIsDefault:true});}constfg=newFormGroup({alpha:makeFormControl('a'),beta:makeFormControl('b'),  ...});

@dylhunn Yeah I agree. Even if the confusing API is tolerated, the confusing type is problematic.

Would it be possible, say, if you explicitly set the type of the FormControl to string likenew FormControl<string>('value'), it is non-nullable but if you do not provide a type,new FormControl('value)', and the type is inferred from the initial value it becomes nullable? Because in current API, even if you set the type of theFormControl as string it becomes nullable so I think this might confuse people. People wouldn't expect a FormControl that they typed asstring and not asstring | null to be nullable. Making this choice explicit somehow, can solve our problem too, we would just type the FormControls with non-nullable types. I don't know if it is possible though, I'm not familiar with angular codebase, just some thoguhts :)

The schmetics could be really nice, like adding the initialValueIsDefault: true to all form controls. But this wouldn't help new code that will be written with the same verbose syntax. But if this is what is needed for typed forms, I'm happy :)

@alxhub Yeah I know, it is just a sweet delusion and a time bomb that is waiting to explode :) We generally try not to use reset or be careful when disabling forms, but it is a dangerous spot.

That was my thought exactly, extend the FormControl class with default values or a utility function.

@alxhub@fatihdogmus@dylhunn Please check here#44513 (comment) a proposal on how to implement strict nullability while giving hints to implementers. I have exactly the same feelings as you do, and I feel here we can do better.

AFAIU, you can't directly pass the type of the model itself to the group. The group expects a type that consistst of AbstractControls, like this(and you need to give it nullable sincenew FormControl returns nullable types):

typeMyFormType={age:FormControl<number|null>;}constformGroup=newFormGroup<MyFormType>({age:newFormControl(0),});

Then, you can access it direclty withformGroup.value.age orformGroup.get('age')?.value and as far as I tested, yes the actual value is a number, this code returns truetypeof this.formGroup.get('age')?.value === 'number'. The code I've tested with

<form[formGroup]="formGroup"><inputtype="number"formControlName="age"/><buttontype="button"(click)="click()">Hebele</button></form>

typeMyFormType={age:FormControl<number|null>;};@Component({selector:'profile',templateUrl:'./profile.component.html',styleUrls:['./profile.component.css'],})exportclassProfileComponent{formGroup=newFormGroup<MyFormType>({age:newFormControl(0),});click(){//prints 'true'console.log(typeofthis.formGroup.get('age')?.value==='number');}}

@fatihdogmus is correct. Just one addition: thenull is optional, you can get rid of it by specifyinginitialValueIsDefault on theFormControl.

This is great to know! That’s awesome 🎉

3. The reset to initial sounds great and should be the deafult. Generally i believe angular should discourage null usage and prefer undefined

Indeed. Angular should provide the best practices/preferred way as default. And provideopt out or extra settings for backwards compatibility.
This way you discourage thewrong(ish) way, instead of the other way around. If doing it the proper way, costs more time/work people might take the easy way.

I agree on theFormRecord type - yes please. Ideally I could do something like this:

constb=newFormBuilder();constform=b.record<Pledge&{[key: `comment-${keyofPledge}`]?:string;}&{[key: `allocation-${keyofPledge}`]?:number;}>()

and get a type error if I add a control to the form that is not a valid key of this object.

„ I dont think the missing types in some areas are a blocker... I do think validators and CVA needs to be typed in future releases. One more thing is formControlName validating that the name actually exists in the parent form group. Didn't see it mentioned in addition to the internal type check.“

This is actually really an important thing. That’s why I use property bindings all the time when using nostack forms. Typos in control names happen so often. Actually this is the main reason for me to use no stack forms. :)
Also refactoring works then fine.

At the very least, make the migration for the<any> a separate migration from any other changes for this RFC, so if you use a third-party tool like Nx that allows you to change what migrations you run you can just disable it before executing all the other migrations.

The migration actually applies a special aliasAnyForUntypedForms for exactly this reason, so it should be quite easy to do a search and replace in your project to remove them all.

Well, since every property, properly has a different type. You'll have to change them one by one. So a search and replace will probably not work, right?

I expect in practice you'd do a search-and-delete :)

When I was playing with earlier versions of this PR, I felt the need to have anInferControls type, which was basically a simpler version ofControlsOf that@NetanelBasal mentions. I agree that a similar type out-of-the-box would be handy. Even if that won't cover all cases, this would simplify a lot of common use-cases.

@NetanelBasal Thanks for your insightful comment.

I expose aControlsOf type in my library that provides this functionality

We will almost certainly add aGuessControlType or similar based on this feedback. I'm yak-shaving a bit about the name because we cannot actuallyguarantee that the result is correct, due to object-valued custom controls.

There isn't a valid case for tuples, as far as I can tell. A FormArray has the same type of controls

What about[string, number], which is not possible with the currentFormArray?

In my opinion, the behavior of the disabled control is undesirable.

I agree this behavior is confusing and bad, but we don't have a strategy for migrating/evolving away from it. Any ideas here? (Of course, we could just tell everyone to usegetRawValue() and deprecatevalue, but that's very surprising.)

I'm wondering if you have considered the following case

You can type this three ways with the current prototype, with increasing levels of strictness:

1. FormGroup<any>
2. FormGroup<{[key string]: FormControl<string>}>
3. FormGroup<{key?: FormControl<string>}>

We will almost certainly add a GuessControlType or similar based on this feedback. I'm yak-shaving a bit about the name because we cannot actually guarantee that the result is correct, due to object-valued custom controls.

Yes, that's correct. Custom value accessors are pretty standard. For example, you'll almost always useFormControl([]) in custom select elements. I'm forcing the consumer to explicitly pass it in my library to get around this problem:

interfaceUser{name:string;// 👇🏻skills:FormControl<string[]>;}

What about [string, number], which is not possible with the current FormArray?

Same. From my experience, you'll usually use the same control type, but let's hear what others have to say.

I agree this behavior is confusing and bad, but we don't have a strategy for migrating/evolving away from it. Any ideas here? (Of course, we could just tell everyone to use getRawValue() and deprecate value, but that's very surprising.)

Now would be a good time to begin the process. Otherwise, it won't happen. You could introduce agetValue() method that returns the same value asgetRawValue() and deprecate bothvalue andgetRawValue(). Then, it could be removed in v14/15 as you decide.

I totally agree disabled is currently working in a weird and unexpected way. getValue seems like a good idea!

getValue(): don't forgetvalueChanges - how should that be migrated to a "not remove disabled controls" thing?

I almost usegetRawValue because I got very surprised about the behaviour ofvalue.

The problem withunknown is that it would break existing code, which goes against one of our primary goals.

Longer term, we hope to remove the defaults for the generics from this proposal, so thatFormControl & friends will always need a generic parameter specified (unless it can be inferred as withnew FormControl(...)). So theanys hopefully won't be around forever.

We've been thinking about this quite a bit.

Pros of usingFormArray<ElemType[]>:

1. FormTuple, if implemented, would look likeFormTuple<[string, number]>, so the array type is consistent between the two classes
2. Implementation is easier, sinceT is directly the control type

Pros of usingFormArray<ElemType>:

1. Looks like the builtinArray<T>
2. More consistent withFormControl andFormGroup
3. More consistent migration

If we don't implementFormTuple then we will certainly change it. Otherwise it's still up in the air, and we'll probably go where the consensus leads us.

I vote forFormArray<ElemType>. That is much clearer.

Thank you for reporting this -- this is a major blocking issue we will need to solve.

Yep - likely we need to look for dynamicimport() as well as staticimport ... from statements.

Regarding extending Forms classes:

Note that we are providing a default typeT = any for all these classes. Any library that declaresMyFormControl extends FormControl is implicitly extendingFormControl<any>, and should continue to work. This is still a theory, and we're very interested in finding out if we broke applications that rely on this approach. Please help us by trying it out and letting us know :)

Note also that extending Forms classes like this is technically unsupported and we recommend against it. We're trying to avoid breaking it though.

RegardingControlValueAccessor

It's becoming more and more clear that we need to typeControlValueAccessor as well. This will probably be a simple<T> on the interface, which will beused inwriteValue and theonChange callbaek.

Regarding extending form controls - why is it an unwanted behaviour? If for example you have a reusable CVA component which encapsulates a form group with built in validation, currently you have to render it even if not shown to get the validation to work (required validation for example). You could for example extend the form control to encapsulate the validation logic and use it with the now "stateless" component

opt-in to stricter typing by defining interfaces that extend the @angular/forms classes.

It's very difficult to get the types right while doing this, due to the many gotchas (reset() and nullability, disabled controls, etc). We studied many different implementations both inside and outside of Google, and they all suffered from unsoundness related to these strange cases (including@ngneat).

So I guess my concern is, how would these changes impact/interact with implementations like mine or@ngneat's? For example, I'm not clear on what will happen to Angular's ControlValueAccessor interface. I assume that any Angular types which become generic would cleanly supersede any custom generic interfaces, but if ControlValueAccessor will remain as it is currently, but FormControl gets a new generic parameter, would the stricter typing of FormControl potentially cause any type conflicts with my hand-rolled generic ValueAccessor interface?

This is a good question! My suspicion would be that custom derived interfaces will either 1) be migrated or 2) benefit from the default generic parameters ofany that we're adding toFormControl, etc, so that they will interact using the previous untyped behavior. That is:

classMyFormControl<T>extendsFormControl{  ...}

implicitly extendsFormControl<any>, so the base class behaves as an untypedFormControl.

Therefore, there should be no direct conflict, but your custom interfaces would need to be updated in order to benefit from any stricter typing.

What would happen if you callreset before thegetValueFrombackend event fires? And what would the type ofdog be?

Let's rename it a little bit to make more sense.

constdog=newFormControl('spot');// dog has type FormControl<string>dog.reset();console.log(dog.value);// null | current behaviour `Default is null`this.getValueFrombackend.subscribe(value=>{dog.setValue(value,{asDefault:true});// beSpotdog.setValue('random');dog.reset();console.log(dog.value);// beSpot});/* Maybe even like this?!this.getValueFrombackend.subscribe(value => {    dog.setDefaultValue(value); // beSpot    dog.setValue('random');    dog.reset();    console.log(dog.value); // beSpot})*/

I believe It should be reset to the latest default value or fall back to the current behavior.

It shouldn't affect types at all. It would behave like a simple setValue but with changing the default value.

In the example you gave, the type ofdog.value isstring, but the value isnull. That means the type would be lying. We definitely want to avoid that.

We could definitely consider allowing the default value to be updated in the future - as long as the new default value is compatible with the type of the control, this should work fine.

While it might be surprising to some, it is how the value object currently behaves and this proposal doesn't intend to make any runtime changes to forms.

Unfortunately that means that the resulting typed forms aren't strictly safe, for example you could have aFormControl<number> that is used with a custom input that happens to use aControlValueAccessor<any> and sets the value to be a string every time, and then when you get.value of the control your value will be typed as anumber but the actual value will be astring.

I would love to see a readonly state added. If readonly the value would still exist in value, validators would still run, etc. The CVA interface could have a new optional setReadonlyState to set that, and if not it would set the disabled state on the CVA (assuming it at least has a setDisabledState).

Most of the time in my current application when we are disabling the form we'd really rather just set inputs to readonly, but that's not easy to do with reactive forms.