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

Support config the behaviours for the option type #228

Open
rainbowatcher opened this issue Apr 11, 2024 · 3 comments
Open

Support config the behaviours for the option type #228

rainbowatcher opened this issue Apr 11, 2024 · 3 comments

Comments

@rainbowatcher
Copy link

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> to id: number | null, but I'm expecting id?: number. Could you please add support for configuring this behavior in export::ts_with_cfg()?

Or do you have a better idea?

@oscartbeaumont
Copy link
Owner

#[specta(optional)] is the best we have right now. I think it exports as id?: number | null.

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.

@rainbowatcher
Copy link
Author

rainbowatcher commented Apr 13, 2024

Thank you for your reply.

I've used #[specta(optional)], which is good, but sometimes it's still not perfect. I get confused when I define a function and call it like this:

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.
as developers often eschew the use of null,
So the function can only be as follows.

function foo(a?: any) {
	thirdPartyFn(a)
}

I have read the issue from rspc oscartbeaumont/rspc#100, And I think the TypeScript modules are specifically designed for generating TypeScript types, so generating more natural TypeScript types should be considered.

@oscartbeaumont
Copy link
Owner

You can use ?? undefined instead, using any is very rarely a good solution (playground).

but yeah as discussed in that other issue we will probaly split the handling of serialization and deserialization so we can potentially automatically apply #[specta(optional)] when using using#[serde(skip_serializing_if = "")] or similar although many questions still remain about how we are going to actually make that work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants