-
-
Notifications
You must be signed in to change notification settings - Fork 34
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
Support config the behaviours for the option type #228
Comments
This is way more of Serde thing than a Specta thing. We are required to copy what is decides to serialize/deserialize the value as although here is some possible improvements around types that implement one and not the other trait. |
Thank you for your reply. I've used type User = { name?: string | null }
// ^ this is specta output type
const user = { name: "tony" }
function foo(a?: string) {
console.log(a)
}
foo(user.name) // this line will throw a error: Type 'null' is not assignable to type 'string | undefined' it must be declare like follow to avoid that error function foo(a?: string | null) {
console.log(a)
} When I call a third-party function within this function, I encounter exceptions again. function foo(a?: any) {
thirdPartyFn(a)
} I have read the issue from rspc specta-rs/rspc#100, And I think the TypeScript modules are specifically designed for generating TypeScript types, so generating more natural TypeScript types should be considered. |
You can use but yeah as discussed in that other issue we will probaly split the handling of serialization and deserialization so we can potentially automatically apply |
Hi, Thanks for the amazing project, I'm building a project using Axum and Specta, I've created a request body with optional fields, However, Specta is converting
id: Option<i32>
toid: number | null
, but I'm expectingid?: number
. Could you please add support for configuring this behavior inexport::ts_with_cfg()
?Or do you have a better idea?
The text was updated successfully, but these errors were encountered: