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
Is your feature request related to a problem? Please describe.
The extensions on scalars that inform codegen what types to use are useful, but seem inconsistent and incomplete
For example, the USCurrency scalar sets codegenScalarType to string which is the serialized type, but not what is expected as a resolver return type, or what is provided in resolver args.
The DateTime scalar sets codegenScalarType to Date | string which is what is expected as a return type of resolvers, but will always serialize to a string, and parse to a Date in args.
Describe the solution you'd like
It would be great if we could have 3 types represented in the extensions of scalars:
The serialized type (we probably already have this in the form of the jsonSchema.type)
A type representing the values that are allowed to be returned from resolver that can correctly be serialized
A type representing parsed values. This may often the the same as 2, but should be stricter in same cases like the date related scalars
Describe alternatives you've considered
Additional context
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
The extensions on scalars that inform codegen what types to use are useful, but seem inconsistent and incomplete
For example, the USCurrency scalar sets
codegenScalarType
tostring
which is the serialized type, but not what is expected as a resolver return type, or what is provided in resolver args.The DateTime scalar sets
codegenScalarType
toDate | string
which is what is expected as a return type of resolvers, but will always serialize to a string, and parse to aDate
in args.Describe the solution you'd like
It would be great if we could have 3 types represented in the extensions of scalars:
Describe alternatives you've considered
Additional context
The text was updated successfully, but these errors were encountered: