-
Notifications
You must be signed in to change notification settings - Fork 115
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
Can we support #[serde(with = "..")]
?
#275
Comments
What if instead of testing capitalization, we generated some code like |
Does that work? If it doesn't compile, I don't think there's anything we can do about that. |
That's what I'm getting at. We shouldn't be the ones deciding that through checking capitalization, we should let the compiler check if whatever the user provided is a type. |
I agree that that would be peferable, but let's say we generate your |
We just let the user get the compiler error. It should be something along the lines of "expected a type, got a module" or "type does not implement TS". That should guide the user to fix the attribute |
Except this needs to work with serde, which accepts a module there... forgot about that |
Still, if we could change the error message to be something like "using |
Instead of trying to make them compatible, we could make it so using |
That'd work! The worst-case there would be that a user had to do #[ts(as = "TypeA")]
field: TypeA To be honest, I share your aversion to infering stuff from the path. It does seem unlikely to break, but relying on it is just a bit iffy. If we're going with the " |
I actually think this is good. In general,
Yeah, it feels like putting way too much trust in what is, effectively, just a string.
Good point, this might actually be difficult to add, so we should be sure it's worth it |
With #299 this can be done as #[ts(as = "_")]
field: TypeA |
Would it make sense for us to parse
#[serde(with = "..")]
as an alias for#[ts(as = "..")]
?serde
seems to, when encountering a field with#[serde(with = "X")]
, (de)serialize withX::(de)serialize
.That means that
#[serde(with)]
can point to a module with two functions, or two a struct implementingSerialize
andDeserialize
.In the 1st case, there's nothing we can do. For case 2, however, we could interpret that as
#[ts(as = "X")]
.So, to support this, we'd need to figure out if
X
is a type or a module path. We could decide that based on capitalization (a::b::C
is probably a type, anda::b::c
is probably a module).If we determine that it's a module, we ignore it. If it's a type, we interpret the annotation as
#[ts(as = "..")]
. It's not bullet-proof, but probably good enough?If we went down that road, it'd make sense to have
#[ts(type = "..")]
or#[ts(as = "..")]
take prescedence over#[serde(with = "..")]
, overriding it.Happy to hear any input on this!
Links
#[serde(with)]
The text was updated successfully, but these errors were encountered: