-
-
Notifications
You must be signed in to change notification settings - Fork 50
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
Emitting optional fields in generated TypeScript #100
Comments
Specta actually supports the btw |
Thanks, |
In my view we do it for two reasons:
There's been some discussion about this over in ts-rs, but even that isn't really beneficial for your use case since it's only discussing serialisation. Specta treats all types as if they're going to be both serialised and deserialised, so it sticks to the lowest common type denominator between the two. Maybe we should be a hint that tells Specta if you're only ever using one, like |
Hi there, thanks so much for this library! I've been trying it out for a few days in a Tauri project and it's been a real pleasure to use so far.
One small point of friction I've encountered is when I have procedures that take complex inputs with a number of optional fields. Let's say I have an query like this:
That results in emitted TypeScript that looks something like this:
On the frontend I can then consume it like this:
This works, but it's a little verbose. I'd like to do something like this:
Much better! And this is much more idiomatic for JavaScript and TypeScript.
I think it would be nice if Specta could support this by adding a
?
prefix (or| undefined
) to the type annotation of optional fields. This could maybe be configurable via a field or struct attribute... but honestly I'm not sure it needs to be.Generally the most idiomatic way to express optionality in TypeScript is like this:
It could also be fine to allow both
null
andundefined
:I think that
fieldname?: T | null
is also the same asfieldname: T | null | undefined
, but there might be nuance -- seeexactOptionalPropertyTypes
.For what it's worth, Serde (and thus rspc) already support deserializing
undefined
intoNone
for anOption<T>
. So in the above example, if I simply omit the nullable fields instead of explicitly setting them tonull
(ignoring the TypeScript errors that yields at the moment), everything works fine -- it's just that the emitted TypeScript doesn't like that.The text was updated successfully, but these errors were encountered: