You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(Assume the data comes from an API so it's not type-checkable on build-time.)
It will accept that data, and p.bestFriend will be Dog[] even though the prop definition was a non-array Dog. We should have a way to be explicit about if we want the prop to be an array or not, so that EntityBuilder can reject array data for a singular property.
Proposal: Typed collection decorator
One proposal is only being explicit about arrays so that EntityBuilder will reject arrays if the field is not annotated with the decorator.
classPersonextendsEntity{
@Type(Dog)bestFriend!: Dog;// this will not be filled with array input
@CollectionType(Dog)pets!: Dog[];// this will be filled with ONLY array input}
Proposal: Separate and single-purpose collection decorator
One proposal is only being explicit about arrays so that EntityBuilder will reject arrays if the field is not annotated with the decorator.
classPersonextendsEntity{
@Type(Dog)bestFriend!: Dog;// this will not be filled with array input
@Type(Dog)
@Collection// can be before `@Type` as well.pets!: Dog[];// this will be filled with ONLY array input}
Upside of a single-purpose collection decorator is that they can be utilized for primitive type properties, as well.
The text was updated successfully, but these errors were encountered:
Assuming the following entity definitions:
If I create an instance of
Person
with the following data:(Assume the data comes from an API so it's not type-checkable on build-time.)
It will accept that data, and
p.bestFriend
will beDog[]
even though the prop definition was a non-arrayDog
. We should have a way to be explicit about if we want the prop to be an array or not, so that EntityBuilder can reject array data for a singular property.Proposal: Typed collection decorator
One proposal is only being explicit about arrays so that EntityBuilder will reject arrays if the field is not annotated with the decorator.
Proposal: Separate and single-purpose collection decorator
One proposal is only being explicit about arrays so that EntityBuilder will reject arrays if the field is not annotated with the decorator.
Upside of a single-purpose collection decorator is that they can be utilized for primitive type properties, as well.
The text was updated successfully, but these errors were encountered: