Upgrade is hard and refactoring too big

[jogelin]

I am writing this issue to share about the upgrade from v1.7.5 to v3.

We are using this library since the beginning in our mono repo and we really liked the fact that we could make our forms typed.

We are trying to keep our repo up to date but with the last upgrade but we investigated what will be the cost of refactoring our forms and it is really too much.

In fact, being forced to create a new type with specific AbtractControl each time we have a complex object is impacting us too much.

And because the upgrade cannot be incremental, we decided to wait until Angular will make its own version. Th the imports will not be the same and we could upgrade step by step.

And now we would like to upgrade to Angular v13 but you don't propose a v1.x compatible version :(

What could we do? Removing simply your library?

[NetanelBasal]

In fact, being forced to create a new type with specific AbtractControl each time we have a complex object is impacting us too much.

I'm not sure what you mean here.

[jogelin]

@NetanelBasal
The 2 main issues we met were:

• Being forced to specify a FormControl when having an array
• Being forced to specify a FormControl on complex type like Date

The consequence is always the same: creating a new type for each form.

So before we were using directly our Domain types or modifying them by using type aliases like Pick, Omit, ...

But being forced to create a new type for each form has a big impact when you have a lot of forms with nested types.

Not saying it is wrong! I understand that this new approach is better! Just saying that the upgrade step is too big for us.

Pragmatically, we would prefer to remove the types of forms and take the risk of having a bug vs duplicating all of our domain types and making our code hard to maintain.

Just sharing kind of a patch approach with a custom ControlsOf:

/* eslint-disable */
import { AbstractControl } from '@angular/forms';
import { FormArray, FormControl, FormGroup } from '@ngneat/reactive-forms';

type NonUndefined<T> = T extends undefined | never ? never : T;
type IsNonUndefinedString<T> = NonUndefined<T> extends string ? T : never;

export type CustomControlsOf<
  T extends Record<string, any>,
  ForceFields extends { controlFields?: string; groupFields?: string; arrayFields?: string } = { controlFields: ''; groupFields: ''; arrayFields: '' }
> = {
  [K in keyof T]: T[K] extends AbstractControl //already a control?
    ? T[K] //already a control!
    : K extends IsNonUndefinedString<ForceFields['controlFields']> // force to be a control?
    ? FormControl<T[K]> // force to be a control!
    : K extends IsNonUndefinedString<ForceFields['groupFields']> // force to be a group?
    ? FormGroup<T[K]> // force to be a group!
    : K extends IsNonUndefinedString<ForceFields['arrayFields']> // force to be an array?
    ? FormArray<T[K]> // force to be an array!
    : NonUndefined<T[K]> extends (infer R)[] //array type?
    ? FormControl<R[]> // array type! -> use control as default
    : NonUndefined<T[K]> extends Record<any, any> // nested type?
    ? FormGroup<SgControlsOf<T[K], ForceFields>> // nested type! -> use group
    : FormControl<T[K]>; //default case -> control
};

In this way, we can override the types of our fields without having to recreate a new type:

form: FormGroup<CustomControlsOf<User, {controlFields: 'permissions'}>>

In this way, permissions will be a FormControl instead of a FormArray

Anyway, thx for the libs you are providing, we are using them a lot ;)

[NetanelBasal]

I see, but I don't think you'll get a solution for these issues in the future built-in types.

[jogelin]

Yeah, I saw you are "participating" :)

I was just thinking that the upgrade could be done step by step because the import will be different :)

You can close this discussion, feel better by sharing it :D

[jogelin]

@NetanelBasal We still have troubles with the refactoring. So as explained above, we are using "our rules" to define what Control we want to generate:

import { AbstractControl } from '@angular/forms';
import { FormArray, FormControl, FormGroup } from '@ngneat/reactive-forms';

type NonUndefined<T> = T extends undefined | never ? never : T;
type IsNonUndefinedString<T> = NonUndefined<T> extends string ? T : never;

export type SgControlsOf<
  T extends Record<string, any>,
  ForceFields extends { controlFields?: string; groupFields?: string; arrayFields?: string } = { controlFields: ''; groupFields: ''; arrayFields: '' }
> = {
  [K in keyof T]: T[K] extends AbstractControl //already a control?
    ? T[K] //already a control!
    : K extends IsNonUndefinedString<ForceFields['controlFields']> // force to be a control?
    ? FormControl<T[K]> // force to be a control!
    : K extends IsNonUndefinedString<ForceFields['groupFields']> // force to be a group?
    ? FormGroup<T[K]> // force to be a group!
    : K extends (IsNonUndefinedString<ForceFields['arrayFields']>) // force to be an array?
    ? (NonUndefined<T[K]> extends (infer R)[] ? FormArray<R, FormControl<R>> : never) // force to be an array!
    : NonUndefined<T[K]> extends (infer R)[] //array type?
    ? FormControl<R[]> // array type! -> use control as default
    : NonUndefined<T[K]> extends Record<any, any> // nested type?
    ? FormGroup<SgControlsOf<T[K], ForceFields>> // nested type! -> use group
    : FormControl<T[K]>; //default case -> control
};

Then we use it like this to be compatible with the internal ControlsOfValueOf:

type UserForm = SgControlsOf<UserGroupDetailForm, { arrayFields: 'permissionSets' }>;

form: FormGroup<ControlsOf<UserForm>>;

By using this we can define that by default we want to use FormControl for our array.

But when we want to use a FormArray, there is again a rule that says that by default we use a FormGroup the type is a Record.
And it makes sense again but in our case, we had to specify FormArray<PermissionSet, FormControl<PermissionSet>>.

We had the reflection to stop trying to fight against the default "rules" but we meet another issue: we use a lot the FormControl for arrays or for Record inside a FormArray because we use a lot of ControlValueAccessor and we can't bind a FormGroup or a FormArray.

So on one side, we have a complex form structure but that matches perfectly the model structure
AND
On the other side, we cannot use ControlValueAccessor correctly anymore.

What do you think? :)

[NetanelBasal]

I'm not sure what the question is 🙂

[jogelin]

Because the v3 enforce the fact that we are creating complex form. How did you manage the case when you have an array of objects which is transformed to a FormArray of FormGroup but in your component you want to create a controlValueAccessor for each item?

I mean I am still not comfortable with the fact that we force the way we bind types to controls. You probably had to solve that too no?

[jogelin]

Are you using the controlOf ? :)

[NetanelBasal]

There is no good way to resolve this issue. Angular forms are very flexible. You can provide whatever you want to a FormControl—for example, an array or an object. We can't distinguish between a FormControl/FormArray/FormGroup when you provide a type.

[strigefleur]

Can relate so much. Lots of forms with model arrays used to be FormControl instead of FormArray by default.

Honestly no idea of smooth migration from v1 - so many breaking changes. Could we please have a choice on the gotchas at least - should it be FormArray by default or not?