Comments (11)
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).
What if instead of testing capitalization, we generated some code like fn does_this_compile() { <#ty as #crate_rename::TS>::name() }
?
from ts-rs.
Does that work? If it doesn't compile, I don't think there's anything we can do about that.
from ts-rs.
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.
from ts-rs.
I agree that that would be peferable, but let's say we generate your does_this_compile
, and it doesn't - what now?
from ts-rs.
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
from ts-rs.
Except this needs to work with serde, which accepts a module there... forgot about that
from ts-rs.
Still, if we could change the error message to be something like "using #[serde(with = "module")]
requires the #[ts(as = "type")]
attribute" that would keep serde working and tell the user how to fix the problem. I don't know if that's possible though
from ts-rs.
Instead of trying to make them compatible, we could make it so using #[serde(with = "..")]
demands using #[ts(as = "..")]
or #[ts(type = "..")]
from ts-rs.
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 "#[serde(with)]
requires a type override" solution, we'll have to consider if the effort/added complexity is worth the small benifit. I'd also be fine with just closing this as wontfix.
from ts-rs.
That'd work! The worst-case there would be that a user had to do
#[ts(as = "TypeA")] field: TypeA
I actually think this is good. In general, #[serde(with = "...")]
changes the type that TypeScript will receive, so #[ts(as = "...")]
should be required. If #[serde(with = "...")]
doesn't change the type, the user should explicitly say that like you did in this snippet
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.
Yeah, it feels like putting way too much trust in what is, effectively, just a string.
If we're going with the "
#[serde(with)]
requires a type override" solution, we'll have to consider if the effort/added complexity is worth the small benifit. I'd also be fine with just closing this as wontfix.
Good point, this might actually be difficult to add, so we should be sure it's worth it
from ts-rs.
That'd work! The worst-case there would be that a user had to do
#[ts(as = "TypeA")] field: TypeA
With #299 this can be done as
#[ts(as = "_")]
field: TypeA
from ts-rs.
Related Issues (20)
- Feature request: `#[ts(bound)]` attribute HOT 13
- Feature request: rust_decimal::Decimal TS implementation HOT 2
- Feature request: `bnum` compatibility HOT 2
- bug: `impl Trait` only allowed in function and inherent method return types, not in trait method return types HOT 4
- TypeList recursion limit HOT 3
- Feature request: Export in the same file HOT 3
- bug: Using `#[ts(rename_all = "...")]` `snake_case`, `SCREAMING_SNAKE_CASE` and `kebab-case` is not compatible with serde
- Randomly failing `imports` test HOT 1
- Unqualified call to `Self::name()`
- `usize` and `isize` should be typed as `bigint` on 64-bit architectures HOT 6
- Feature request: `serde-wasm-bindgen` compatibility. HOT 4
- Feature request: How to export multiple types to the same file HOT 4
- Feature request: Typed array types HOT 1
- bug: Tuples cause imports to be missed HOT 5
- bug: files are missing final newlines
- bug: `export::path:absolute` function fails when `TS_RS_EXPORT_DIR` is set to an absolute path and the `path_bug` test is executed
- bug: TS generated tests fail on struct with `serde_json::Value` type when running `cargo test`. HOT 2
- `ts(optional)` should be working on any which has `skip_serializing_if` HOT 1
- Add all of `ts(function)` to docs. HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ts-rs.