Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reactive forms are not strongly typed #13721

Open
asfernandes opened this issue Dec 30, 2016 · 118 comments · May be fixed by #40772
Open

Reactive forms are not strongly typed #13721

asfernandes opened this issue Dec 30, 2016 · 118 comments · May be fixed by #40772

Comments

@asfernandes
Copy link

@asfernandes asfernandes commented Dec 30, 2016

[x] feature request
  • Angular version: 2

Reactive forms is meant to be used in complex forms but control's valueChanges are Observable<any>, which are totally against good practices for complex code.

There should be a way to create strongly typed form controls.

@Toxicable
Copy link
Contributor

@Toxicable Toxicable commented Dec 31, 2016

related #11279

@asfernandes
Copy link
Author

@asfernandes asfernandes commented Jan 1, 2017

This is not related to #11279.

@Toxicable
Copy link
Contributor

@Toxicable Toxicable commented Jan 1, 2017

Please explain how it is not related?
What you want is for Abstract Control to be Generic right? That is the only way that valueChanges can have a type that is not Observable<any> there would be no other way to infer the type.
Which is exactly what #5404 is asking, which means this is related to #11279
If there is another way this could be implemented without making AbstractControl a generic please explain that.

@asfernandes
Copy link
Author

@asfernandes asfernandes commented Jan 1, 2017

Using get<Type> as in #11279 is definitively wrong solution. If TypeScript had somethign like Java Unbounded Wildcard, get would use it, and not any. Maybe something can be done in the same manner with a empty interface?

There is also https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-1.html keyof. TypeScript 2.1 features may be very interesting to study to implement strongly typed form controls.

The way it is currently, unfortunately, I do not thing it's usable for large app and I need to design something on top of it.

@Toxicable
Copy link
Contributor

@Toxicable Toxicable commented Jan 9, 2017

I just noticed that in TS 2.2 (https://github.com/Microsoft/TypeScript/wiki/Roadmap#22-february-2017) that they have planned Default Generic Types (microsoft/TypeScript#2175) once we have this I think it might be a good idea to revisit this issue since we could make AbstractControl generic like AbstractControl<T = any> where the T is the type of the value returned by valueChanges which would be an Observable<T>. It would not be a good idea to do it currently since it would a massive breaking change but with default generics, unless I misunderstand them, it will not be a breaking change.

@Toxicable
Copy link
Contributor

@Toxicable Toxicable commented Feb 19, 2017

Small update on this, looks like Default Generics have been been moved to TS2.3 . So with the support of TS 2.1 by Angular with version 4.0 it should not be long after that before they're able to support TS 2.3 which is now when we should wait to revisit this.

@desfero
Copy link

@desfero desfero commented May 15, 2017

TypeScript 2.3 with Default Generic Types is already here, do we have any plans when support for TS 2.3 in angular will be ready?

@Toxicable
Copy link
Contributor

@Toxicable Toxicable commented May 15, 2017

@desfero waiting on #16707 for the build to be upgraded to TS2.3

@kemmis
Copy link

@kemmis kemmis commented Aug 10, 2017

+1 would love to see this feature. Anybody working on it?

@Toxicable
Copy link
Contributor

@Toxicable Toxicable commented Aug 10, 2017

#16828
Currently blocked on microsoft/TypeScript#16229

@rpbeukes
Copy link

@rpbeukes rpbeukes commented Oct 30, 2017

This might be of use - Angular Typesafe Reactive Forms

@Toxicable
Copy link
Contributor

@Toxicable Toxicable commented Oct 30, 2017

Small update on this:
As per my comment here: #16828 (comment)
implementing generics into the current Forms API is not possible without breaking changes.
So either breaking changes are needed
Or a full forms rewrite

@Toxicable
Copy link
Contributor

@Toxicable Toxicable commented Oct 31, 2017

So turns out my previous comment was incorrect.
I was able to implement this on the current Forms API as you can see here #20040

@howiempt
Copy link

@howiempt howiempt commented Oct 31, 2017

@Toxicable that still has the problem of lacking the ability to refactor safely. get('person') for example, is not really using the symbol itself. The example above, from @rpbeukes, has a retrofitted way of basically using the object symbol eg. get(obj.person) without using the string. That would be preferred over just having return types.

@Toxicable
Copy link
Contributor

@Toxicable Toxicable commented Nov 1, 2017

@howiempt

get('person') for example, is not really using the symbol itself

I have no idea what you mean by this, what symbol are you referring to here?
In my implementation you can do something like

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

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

get(obj.person) without using the string

This lacks the ability to traverse multiple FormGroups.
While my method is unable to infer the types in this scenario the idea of my PR is to add Generic types without breaking changes or introducing any new API's (aside from generics)

@howiempt
Copy link

@howiempt howiempt commented Nov 1, 2017

@Toxicable I understand you're change is meant to not break things, not trying to criticize your solution. The other implementation (retrofitted) allows an actual property to be used rather than a string. By referencing the the field by string, if that property name changes, builds break, which for me isn't very safe. For example, changing the field name from 'name' to 'firstName', would break if I didn't change all the g.get('name') references. If I could do something like

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>

They would all be tight references. The retrofit solution does it in a slightly hacky way but does solve that problem as well.

@rpbeukes
Copy link

@rpbeukes rpbeukes commented Nov 1, 2017

@Toxicable thanx for the PR. Looking forward using it :)

I do agree with @howiempt, if we can get something like this it would be first prize:

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

Again, I don't really know how feasible this is within the greater scope of things.
I trust your judgement.

Keep up the good work and thanx for the quick response.

@Toxicable
Copy link
Contributor

@Toxicable Toxicable commented Nov 1, 2017

I think that this method of accessing other controls is not related to adding generics.
Feel free to open another issue about it however

@howiempt
Copy link

@howiempt howiempt commented Nov 1, 2017

I really don't think that having the return type set is really "strongly typed", seems like half of the implementation required, but it is a step in the right direction.

@Quramy
Copy link

@Quramy Quramy commented Nov 30, 2017

Hi, I've released https://github.com/Quramy/ngx-typed-forms for workaround of this issue. Please check it out 😄

@nicu-chiciuc
Copy link

@nicu-chiciuc nicu-chiciuc commented Dec 1, 2017

@Quramy I tried to use your package several weeks ago and as I remember, it doesn't really do a lot of enforcement :(

dylhunn added a commit that referenced this issue Aug 12, 2021
This PR adds generics to `AbstractControl` classes as well as `FormBuilder`. The old behavior of these classes can be obtained by providing `<any>` where a generic is expected. There are still two major bugs: types are not inferred on FormArray, and FormState shows up in control types unexpectedly.

BREAKING CHANGE: This adds generics to several forms APIs, and will break any uses of the modified APIs that have not been migrated to provide an explicit `<any>`.

Specifically, `AbstractControl` and descendents (`FormControl`, `FormGroup`, and `FormArray`) have been modified, as well as `FormBuilder`.

Closes #13721.
dylhunn added a commit to dylhunn/angular that referenced this issue Aug 18, 2021
This PR adds generics to `AbstractControl` classes as well as `FormBuilder`. The old behavior of these classes can be obtained by providing `<any>` where a generic is expected. There are still two major bugs: types are not inferred on FormArray, and FormState shows up in control types unexpectedly.

BREAKING CHANGE: This adds generics to several forms APIs, and will break any uses of the modified APIs that have not been migrated to provide an explicit `<any>`.

Specifically, `AbstractControl` and descendents (`FormControl`, `FormGroup`, and `FormArray`) have been modified, as well as `FormBuilder`.

Closes angular#13721.
@alxhub alxhub added this to Inbox in Feature Requests via automation Sep 2, 2021
@alxhub alxhub moved this from Inbox to Proposed Projects in Feature Requests Sep 2, 2021
@alxhub alxhub moved this from Proposed Projects to In Progress in Feature Requests Sep 2, 2021
@ChrTall
Copy link

@ChrTall ChrTall commented Sep 3, 2021

Is this Featue on the roadmap for Angular 13 ?

@elliotwesoff
Copy link

@elliotwesoff elliotwesoff commented Sep 13, 2021

Just throwing my two cents in...

Strongly typing DTOs (interfaces) for data exchange between server and client is already a thing, for obvious reasons. Being able to apply these DTO types to a form, which gets sent directly to a server, seems like a no-brainer to me. Can we please have this in angular 13? I would love to be able to provide a type argument to a form group:

this.userForm = new FormGroup<IUser>({ ... });

@BeGj
Copy link

@BeGj BeGj commented Sep 20, 2021

Any news on this? I think it's mentioned in the official roadmap

Better developer ergonomics with strict typing for @angular/forms

We will work on implementing stricter type checking for reactive forms. This way, we let developers catch more issues during development time, enable better text editor and IDE support, and improve the type checking for reactive forms.

dylhunn added a commit to dylhunn/angular that referenced this issue Sep 20, 2021
This PR adds generics to `AbstractControl` classes as well as `FormBuilder`. The old behavior of these classes can be obtained by providing `<any>` where a generic is expected. There are still two major bugs: types are not inferred on FormArray, and FormState shows up in control types unexpectedly.

BREAKING CHANGE: This adds generics to several forms APIs, and will break any uses of the modified APIs that have not been migrated to provide an explicit `<any>`.

Specifically, `AbstractControl` and descendents (`FormControl`, `FormGroup`, and `FormArray`) have been modified, as well as `FormBuilder`.

Closes angular#13721.
dylhunn added a commit to dylhunn/angular that referenced this issue Sep 21, 2021
This PR adds generics to `AbstractControl` classes as well as `FormBuilder`. The old behavior of these classes can be obtained by providing `<any>` where a generic is expected. There are still two major bugs: types are not inferred on FormArray, and FormState shows up in control types unexpectedly.

BREAKING CHANGE: This adds generics to several forms APIs, and will break any uses of the modified APIs that have not been migrated to provide an explicit `<any>`.

Specifically, `AbstractControl` and descendents (`FormControl`, `FormGroup`, and `FormArray`) have been modified, as well as `FormBuilder`.

Closes angular#13721.
dylhunn added a commit to dylhunn/angular that referenced this issue Sep 21, 2021
This PR adds generics to `AbstractControl` classes as well as `FormBuilder`. The old behavior of these classes can be obtained by providing `<any>` where a generic is expected.

BREAKING CHANGE: This adds generics to several forms APIs, and will break any uses of the modified APIs that have not been migrated to provide an explicit `<any>`.

Specifically, `AbstractControl` and descendents (`FormControl`, `FormGroup`, and `FormArray`) have been modified, as well as `FormBuilder`.

Issue angular#13721.
@dylhunn
Copy link
Contributor

@dylhunn dylhunn commented Sep 21, 2021

Any news on this?

I am currently spending 80% of my time on this. I cannot promise any specific dates, but the roadmap tentatively looks like this:

  • September: finish implementation on the prototype. We will probably add a FormTuple class, but it's otherwise very close to complete. If you're curious, the in-progress commit is linked to this issue.
  • October: check that google3 internal migration is seamless (simply adding explicit <any> type params at call sites should preserve the exact old behavior). If there are any big compatibility issues, we'll find them here.
  • November: publish an RFC, with emphasis on important design questions (i.e. whether to capture AbstractControl types in the type parameters, the tradeoffs of FormArray<string[]> vs FormArray<string>, etc).
  • November: publish a downloadable version of the package that people can swap in to try out, and collect info on whether it causes any breakages.
  • May: ship it with v14, together with a migration schematic. I'm aware that this has slipped from v13 -- unfortunately, there's just not time for the RFC or google3 migration before v13.

Again, I can't promise these dates, but I think the schedule is reasonable. The biggest risk is that the google3 migration uncovers a show-stopping backwards incompatibility.

dylhunn added a commit to dylhunn/angular that referenced this issue Sep 21, 2021
This PR adds generics to `AbstractControl` classes as well as `FormBuilder`. The old behavior of these classes can be obtained by providing `<any>` where a generic is expected.

BREAKING CHANGE: This adds generics to several forms APIs, and will break any uses of the modified APIs that have not been migrated to provide an explicit `<any>`.

Specifically, `AbstractControl` and descendents (`FormControl`, `FormGroup`, and `FormArray`) have been modified, as well as `FormBuilder`.

Issue angular#13721.
@zijianhuang
Copy link

@zijianhuang zijianhuang commented Sep 21, 2021

@dylhunn

It will be good to publish some best practices of using current reactive forms, for easier migration in the future when strongly typing is available.

dylhunn added a commit to dylhunn/angular that referenced this issue Sep 22, 2021
This PR adds generics to `AbstractControl` classes as well as `FormBuilder`. The old behavior of these classes can be obtained by providing `<any>` where a generic is expected.

BREAKING CHANGE: This adds generics to several forms APIs, and will break any uses of the modified APIs that have not been migrated to provide an explicit `<any>`.

Specifically, `AbstractControl` and descendents (`FormControl`, `FormGroup`, and `FormArray`) have been modified, as well as `FormBuilder`.

Issue angular#13721.
dylhunn added a commit to dylhunn/angular that referenced this issue Sep 22, 2021
This PR adds generics to `AbstractControl` classes as well as `FormBuilder`. The old behavior of these classes can be obtained by providing `<any>` where a generic is expected.

BREAKING CHANGE: This adds generics to several forms APIs, and will break any uses of the modified APIs that have not been migrated to provide an explicit `<any>`. Specifically, `AbstractControl` and descendents (`FormControl`, `FormGroup`, and `FormArray`) have been modified, as well as `FormBuilder`.

Issue angular#13721.
dylhunn added a commit to dylhunn/angular that referenced this issue Sep 22, 2021
This PR adds generics to `AbstractControl` classes as well as `FormBuilder`. The old behavior of these classes can be obtained by providing `<any>` where a generic is expected.

BREAKING CHANGE: This adds generics to several forms APIs, and will break any uses of the modified APIs that have not been migrated to provide an explicit `<any>`. Specifically, `AbstractControl` and descendents (`FormControl`, `FormGroup`, and `FormArray`) have been modified, as well as `FormBuilder`.

Issue angular#13721.
@Harpush
Copy link

@Harpush Harpush commented Sep 22, 2021

@dylhunn You said you will maybe add FormTuple - I believe FormRecord is important too. Currently FormGroup with types will be weird with functions like addControl unless they are with optional keys. There are some cases where a FormRecord is required when we want it to act more like a FormArray but for objects. Might as well remove the RemoveControl and AddControl methods from the regular FormGroup if implemented. The only reason to maybe stay with them is a "union" form - but maybe it requires a specific solution instead?

@MBuchalik
Copy link

@MBuchalik MBuchalik commented Sep 22, 2021

@dylhunn It would be nice if your approach also supported Objects inside FormControls. This is a shortcoming I noticed in multiple PRs.

Potential Use Cases Imagine you have a TimePicker component that creates Date objects. Then you most likely just want to store these Date objects in a FormControl. That could break if you do inference like "there is an object in my model, so it must correspond to a FormGroup".

Other Use Case: A photo taking component, allowing you to get photos in a shape like:

interface MyPhoto {
  data: Blob;
  timeTaken: Date;
  dimensions: {
    width: number;
    height: number;
  }
}

IMHO, using a FormGroup for an MyPhoto item would not be the ideal way, since each MyPhoto is an "atomic" piece of infomation.

Additionally: I believe that all current PRs do not perform any type inference in AbstractControl.get(). Wouldn't inference be possible using Template Literal Types?

@MikeJerred
Copy link
Contributor

@MikeJerred MikeJerred commented Sep 22, 2021

@dylhunn You said you will maybe add FormTuple - I believe FormRecord is important too. Currently FormGroup with types will be weird with functions like addControl unless they are with optional keys. There are some cases where a FormRecord is required when we want it to act more like a FormArray but for objects. Might as well remove the RemoveControl and AddControl methods from the regular FormGroup if implemented. The only reason to maybe stay with them is a "union" form - but maybe it requires a specific solution instead?

This makes perfect sense, however it breaks backward compatibility quite drastically. Having FormGroup behave as one would expect a FormRecord/FormDictionary to behave allows you to type it as and be backwards compatible. A proper type-safe control that cannot have controls added/removed at run-time could then be added separately.

However if backwards compatibility can be broken, then FormRecord makes by far the most sense to me.

@gaplo917
Copy link

@gaplo917 gaplo917 commented Sep 22, 2021

Any news on this?

I am currently spending 80% of my time on this. I cannot promise any specific dates, but the roadmap tentatively looks like this:

  • September: finish implementation on the prototype. We will probably add a FormTuple class, but it's otherwise very close to complete. If you're curious, the in-progress commit is linked to this issue.
  • October: check that google3 internal migration is seamless (simply adding explicit <any> type params at call sites should preserve the exact old behavior). If there are any big compatibility issues, we'll find them here.
  • November: publish an RFC, with emphasis on important design questions (i.e. whether to capture AbstractControl types in the type parameters, the tradeoffs of FormArray<string[]> vs FormArray<string>, etc).
  • November: publish a downloadable version of the package that people can swap in to try out, and collect info on whether it causes any breakages.
  • May: ship it with v14, together with a migration schematic. I'm aware that this has slipped from v13 -- unfortunately, there's just not time for the RFC or google3 migration before v13.

Again, I can't promise these dates, but I think the schedule is reasonable. The biggest risk is that the google3 migration uncovers a show-stopping backwards incompatibility.

@dylhunn Thank you for your hardworking.

Do you have any internal discussion about this thread #13721 (comment) ?


=== Updated 23 Sep 2021 : Angular public API classes are Final, the following approach is not a suggested way to work on Angular Form. To prevent confusion, I strikethrough all of them ===

I reviewed the PR and notice it is a "value type" approach. It implies that developers CANNOT enjoy strictly-typed environment when they are going to build a fancy FormGroup with customized FormControl.

Let's say, I have a use case of submitting Array of FormGroup and I want to build a UserFormGroup to encapsulate business logic of transforming form model to API request i.e. .toApiRequest()

class UserFormGroup extends FormGroup {
   toApiRequest() {
     // some logics to process `this.value` to a API request
      return {
        someKey: this.value.someKey,
        someDate: formatDate(this.value.someDate)
      }
   }
}
const arr = new FormArray<{ someKey: string, someDate: Date}>
const userForm = new UserFormGroup<{ someKey: string, someDate: Date}>()
userForm.setValue({
  someKey: 'some thing',
  someDate: '2021-1-1'
})
arr.push(userForm) // not possible to have type check to enforce `UserFormGroup`

// not strictly typed 
arr.controls  // return AbstractControl[] instead of UserFormGroup[]

// I need to force cast it
const apiRequests = (arr.controls as UserFormGroup[]).map(it => it.toApiRequest())

I highlighted the implementation difference of control type and value type.

The PR of value type
master...dylhunn:typed-formsdiff-61abe7c733b66d542f4f5bd4365382ab7c6a7a55327e3b7cb09d46b6c376b561L1986-R2115

My works on control type
https://github.com/gaplo917/angular-typed-forms/blob/master/projects/angular-typed-forms/src/lib/forms/typed-form-array.ts#L21-L22

P.S. My previous project have to process hundreds of complex form inputs from different scenarios. There are lots of scenarios users have to input a list of form ("SomeFormArray<SomeFormGroup<SomeType>>") and submit them to server. That's why I need better maintenance of the form input codes by building this to get strictly typed and type-lossless angular form with custom encapsulation.
I just raised out my concerns. If Angular Team believe my use case is rare, I would respect their professional design decisions.

@eneajaho
Copy link
Contributor

@eneajaho eneajaho commented Sep 22, 2021

@gaplo917

I have seen that the Angular public API classes are Final, they should not be extended.

So I don't think this will be supported.

class UserFormGroup extends FormGroup { }

@gaplo917
Copy link

@gaplo917 gaplo917 commented Sep 22, 2021

@gaplo917

I have seen that the Angular public API classes are Final, they should not be extended.

So I don't think this will be supported.

class UserFormGroup extends FormGroup { }

Thanks for pointing out. Never read that before.

As typescript don't support final class, so before that I believe that every Angular class can be extended by default. Let alone, typescript did compile without any issue.

Glad that my all-time intentions is only to add new behaviors(function) instead of overriding protected behaviors in typescript.

@jayoungers
Copy link

@jayoungers jayoungers commented Sep 22, 2021

@dylhunn It would be nice if your approach also supported Objects inside FormControls. This is a shortcoming I noticed in multiple PRs.

Agreed: I think you'd definitely need to be able to specify what constitutes an individual FormControl value, and not make assumptions based on a full interface.

I have seen that the Angular public API classes are Final, they should not be extended.

So I don't think this will be supported.

class UserFormGroup extends FormGroup { }

I can understand the mentality that doing so could be considered risky, but if you're extending the class and only adding to it (or adjusting public members), that seems perfectly reasonable. Given the current state of the module, from a reusability standpoint it's easier to extend the class for a given use case opposed to creating factory functions.

@infacto
Copy link

@infacto infacto commented Sep 22, 2021

FormControl value has any type (formState). We could add a generic type for it.

myControl: FormControl<number>;
myControl = new FormControl(42);

But since formState (the first arg) can have multiple types (incl. an object what describes the value), we have to implement a bit more.

dylhunn added a commit to dylhunn/angular that referenced this issue Sep 22, 2021
This PR adds generics to `AbstractControl` classes as well as `FormBuilder`. The old behavior of these classes can be obtained by providing `<any>` where a generic is expected.

BREAKING CHANGE: This adds generics to several forms APIs, and will break any uses of the modified APIs that have not been migrated to provide an explicit `<any>`. Specifically, `AbstractControl` and descendents (`FormControl`, `FormGroup`, and `FormArray`) have been modified, as well as `FormBuilder`.

Issue angular#13721.
@dylhunn
Copy link
Contributor

@dylhunn dylhunn commented Sep 22, 2021

Many of you have brought up some of the issues we intend to address in the RFC. Here are some preliminary comments on the main points above:

@gaplo says:

I reviewed the PR and notice it is a "value type" approach

There is indeed a tradeoff between "value types" and "control types." We chose to use value types for this proposal because it allows users to reuse their existing interfaces and data models, but the cost is that you lose some type information when you access .controls on a FormGroup, for example. (We might be able to work around this by having the exported constructor be value-typed, but the internal implementation be control-typed; it's TBD currently.)

@gaplo917 says:

build a fancy FormGroup with customized FormControl

We don't support extending Forms classes, so please don't do this -- your code could break at any time.

@MBuchalik says:

It would be nice if your approach also supported Objects inside FormControls.

I agree, this is really important. This implementation already works fine with an object-valued FormControl, but I'm not sure if it works with FormControls that have nested objects. I'll add some tests to check, otherwise we might need more design refinement here.

@MBuchalik says:

I believe that all current PRs do not perform any type inference in AbstractControl.get()

I thought it wasn't possible at first, but you're right that template literal types might be powerful enough. I'm not sure if we're going to do this though -- .get() is honestly too permissive of an API, and we should probably discourage its use rather than support it with a bunch of "close enough" type hacks. I may try adding types and see how ugly it is.

@Harpush says:

Currently FormGroup with types will be weird with functions like addControl unless they are with optional keys

We are not going to remove any existing functionality from FormGroup, such as addControl or removeControl. You actually guessed the solution in your comment: we'll allow you to remove controls, but only if they're optional! Similarly, you can add controls, but only if they're in the type.

@Harpush says:

There are some cases where a FormRecord is required when we want it to act more like a FormArray but for objects.

I don't think we actually need FormRecord to handle this case. You can give your FormGroup an index type to support any control you might want to add, within the index constraint. Here's an example of a Person type with a numeric age control, and then an unlimited number of string controls that can be added dynamically (this works and is tested with the current implementation):

interface Person {
  age: number;
  [other: string]: unknown;
}

@MartinJohns
Copy link

@MartinJohns MartinJohns commented Sep 22, 2021

You can give your FormGroup an index type to support any control you might want to add, within the index constraint. Here's an example of a Person type with a numeric age control, and then an unlimited number of string controls that can be added dynamically (this works and is tested with the current implementation):

Just be aware that this reduces the type safety of your code, as it allows you to assign an arbitrary type to the age property (not only number).

@Harpush
Copy link

@Harpush Harpush commented Sep 22, 2021

@dylhunn Concerning the optional keys removal i believe that 99% of the cases are one of three options:

  1. A closed form group based on an object where add and remove has no meaning
  2. An open type that acts like a record/dictionary only
  3. Some kind of discriminated union which currently has no solution here except optional types which isn't ideal by all means.

Lets take addControl - what will it accept? keyof? If yes then it actually has no meaning except optional which is yet to be added. I highly doubt anyone would need that though. Same for contains for example - keyof will already be there as its typed unless all optional and not added yet. And anyway optional can be a form control with value null unless you don't want the key and probably back to union.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment