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 like formName.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:

const dog = new FormControl<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 to null 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 the initialValueIsDefault 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 an initialValueIsDefault property on a FormGroup. Consider the following pedantic example:

const nullableDog = new FormControl<string|null> = ('spot');
const nonNullableCat = new FormControl<string> = ('tabby', {initialValueIsDefault: true});
const animals = new FormGroup({
  cat: nonNullableCat,
  dog: nullableDog,
}, /* hypothetical property on a group */ {initialValueIsDefault: true});

What happens here? The two FormControls 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 your FormControls. 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 the reset() problem - reset() on a FormControl<string> will set it to a null value in spite of its strongly typed nature. A similar problem exists with FormGroup.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 of FormControls with options set is challenging. A helper method could make this simpler:

function makeFormControl<T>(value: T): FormControl<T> {
  return new FormControl(value, {initialValueIsDefault: true});
}

const fg = new FormGroup({
  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 like new 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 the FormControl as string it becomes nullable so I think this might confuse people. People wouldn't expect a FormControl that they typed as string and not as string | 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 since new FormControl returns nullable types):

type MyFormType = {
  age: FormControl<number | null>;
}

const formGroup = new FormGroup<MyFormType>({
  age: new FormControl(0),
});

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

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

type MyFormType = {
  age: FormControl<number | null>;
};
@Component({
  selector: 'profile',
  templateUrl: './profile.component.html',
  styleUrls: ['./profile.component.css'],
})
export class ProfileComponent {
  formGroup = new FormGroup<MyFormType>({
    age: new FormControl(0),
  });

  click() {
    //prints 'true'
    console.log(typeof this.formGroup.get('age')?.value === 'number');
  }
}

@fatihdogmus is correct. Just one addition: the null is optional, you can get rid of it by specifying initialValueIsDefault on the FormControl.

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 provide opt out or extra settings for backwards compatibility.
This way you discourage the wrong(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 the FormRecord type - yes please. Ideally I could do something like this:

const b = new FormBuilder();
const form = b.record<Pledge & {
    [key: `comment-${keyof Pledge}`]?: string;
} & {
    [key: `allocation-${keyof Pledge}`]?: 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 alias AnyForUntypedForms 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 an InferControls type, which was basically a simpler version of ControlsOf 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 a ControlsOf type in my library that provides this functionality

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.

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 current FormArray?

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 use getRawValue() and deprecate value, 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 use FormControl([]) in custom select elements. I'm forcing the consumer to explicitly pass it in my library to get around this problem:

interface User {
  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 a getValue() method that returns the same value as getRawValue() and deprecate both value and getRawValue(). 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 forget valueChanges - how should that be migrated to a "not remove disabled controls" thing?

I almost use getRawValue because I got very surprised about the behaviour of value.

The problem with unknown 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 that FormControl & friends will always need a generic parameter specified (unless it can be inferred as with new FormControl(...)). So the anys hopefully won't be around forever.

We've been thinking about this quite a bit.

Pros of using FormArray<ElemType[]>:

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

Pros of using FormArray<ElemType>:

1. Looks like the builtin Array<T>
2. More consistent with FormControl and FormGroup
3. More consistent migration

If we don't implement FormTuple 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 for FormArray<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 dynamic import() as well as static import ... from statements.

Regarding extending Forms classes:

Note that we are providing a default type T = any for all these classes. Any library that declares MyFormControl extends FormControl is implicitly extending FormControl<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.

Regarding ControlValueAccessor

It's becoming more and more clear that we need to type ControlValueAccessor as well. This will probably be a simple <T> on the interface, which will beused in writeValue and the onChange 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 of any that we're adding to FormControl, etc, so that they will interact using the previous untyped behavior. That is:

class MyFormControl<T> extends FormControl {
  ...
}

implicitly extends FormControl<any>, so the base class behaves as an untyped FormControl.

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 call reset before the getValueFrombackend event fires? And what would the type of dog be?

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

const dog = new FormControl('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}); // beSpot
     dog.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 of dog.value is string, but the value is null. 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 a FormControl<number> that is used with a custom input that happens to use a ControlValueAccessor<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 a number but the actual value will be a string.

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.