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 current allowed string proxy types, boolean, number, date, etc. do not adequately describe every conceivable use case. We should be able to specify any type that can be serialized to a string.
Describe the solution you'd like
We should allow stringProxy to receive the predefined types of 'number' | 'boolean' | 'date' etc, or pass an object with toString, toValue functions: e.g.
// given the schemaz.object({wrapped: z.object({_value: z.string()})})// the proxy could be used like this// type inference could make this more concisetypeWrapperType={_value: T}letproxyValue=stringProxy<WrapperType>(superform,'wrapped',{toValue: (value: string)=>({_value: value}),toString: (value: WrapperType)=>value._value,})
Describe alternatives you've considered
The transformation can also take place in the schema, but given the concept of these proxies, it makes sense to also handle some non-primitive types here
Additional context
Due to limitations of Date object in JS, we use the CalendarDate object from @internationalized/date (this also provides interoperability with components built with the melt-ui library)
I took a quick look at the code, and it doesn't seem too complex (I may, of course, be missing some cases I hadn't considered), I'd be happy to submit a PR, but wanted to sanity check the idea, and ask if this had already been considered and rejected. (I didn't find any related issues though)
The text was updated successfully, but these errors were encountered:
Sounds good, please make a PR! Two extra options like that will be a nice non-breaking feature. My only concern is the type parameter, but I hope it will work fine.
Is your feature request related to a problem? Please describe.
The current allowed string proxy types, boolean, number, date, etc. do not adequately describe every conceivable use case. We should be able to specify any type that can be serialized to a string.
Describe the solution you'd like
We should allow stringProxy to receive the predefined types of 'number' | 'boolean' | 'date' etc, or pass an object with toString, toValue functions: e.g.
Describe alternatives you've considered
The transformation can also take place in the schema, but given the concept of these proxies, it makes sense to also handle some non-primitive types here
Additional context
Due to limitations of Date object in JS, we use the CalendarDate object from
@internationalized/date
(this also provides interoperability with components built with the melt-ui library)I took a quick look at the code, and it doesn't seem too complex (I may, of course, be missing some cases I hadn't considered), I'd be happy to submit a PR, but wanted to sanity check the idea, and ask if this had already been considered and rejected. (I didn't find any related issues though)
The text was updated successfully, but these errors were encountered: