Add #[ts(optional)] to struct

[gustavo-shigueo]

Goal

Allow the use of #[ts(optional)] on struct definitions
Closes #364

Checklist

• I have followed the steps listed in the Contributing guide.
• If necessary, I have added documentation related to the changes made.
• I have added or updated the tests related to the changes made.

[NyxCode]

Love the idea. Would also like to hear what @Nutomic and @dessalines think.

I'm not yet sure if re-using the same #[ts(optional)] on a struct is a good idea syntax-wise, but maybe it'll grow on me.

[dessalines]

Excellent! Yep this would really gonna clean up our structs. Thx!

[NyxCode]

@gustavo-shigueo A problem I see with this implementation is that all fields have to be Option<T>, otherwise this error is emitted: error: 'optional' can only be used on an Option<T> type.

We could fix that by trying to figure out if a field is an Option, and if it isn't, using the default behaviour. But like the current handling of #[ts(optional)], that's fragile, and breaks with type aliases.

Maybe we can move that logic from the macro to the runtime, where we actually know if a type is an Option or not.

[gustavo-shigueo]

@gustavo-shigueo A problem I see with this implementation is that all fields have to be Option<T>, otherwise this error is emitted: error: 'optional' can only be used on an Option<T> type.

Damn, I forgot about that

We could fix that by trying to figure out if a field is an Option, and if it isn't, using the default behaviour. But like the current handling of #[ts(optional)], that's fragile, and breaks with type aliases.

Yeah, that would probably not be a great idea

[gustavo-shigueo]

I implemented a band-aid fix for the problem, but we should probably look into a better way to detect the Option type

[gustavo-shigueo]

Maybe we can move that logic from the macro to the runtime, where we actually know if a type is an Option or not.

We could add a const IS_OPTION: bool = false to the TS trait and set it to true in our impl<T: TS> TS for Option<T>. That shouldn't even be a breaking change since the trait provides a default value

[gustavo-shigueo]

@NyxCode I have implemented this idea for you to take a look, I also change Optional into an enum, this way it is impossible to represent the invalid Optional { optional: false, nullable: true }

[gustavo-shigueo]

The downside of this implementation is that there is no compile time error for

#[derive(TS)]
struct Foo {
    #[ts(optional)]
    foo: i32
}

Instead, this will panic when the user attempts to export their types. I don't quite like this because ts-rs usually works in a "If it compiles, you're good" way, but here we get something that compiles and doesn't work.

[NyxCode]

Nice work! I have an idea how to get this compile-time checked, lemme see if that actually works though..

[gustavo-shigueo]

Another option is just remove this whole thing, this way there'll be no panic (still, no compiler error). What will happen is that #[ts(optional)] will just do nothing when not using an Option type

[gustavo-shigueo]

I'm not yet sure if re-using the same #[ts(optional)] on a struct is a good idea syntax-wise, but maybe it'll grow on me.

Good point, maybe at the struct level we should call it something like optional_fields

[gustavo-shigueo]

maybe at the struct level we should call it something like optional_fields

@NyxCode I've applied this change, but if you think of a better name, feel free to push a commit here

[gustavo-shigueo]

I also added the breaking change tag because this will break manual implementations of TS. As always, the feature we need to avoid that is unstable lol (rust-lang/rust#29661)