-
Notifications
You must be signed in to change notification settings - Fork 94
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 serde flatten for Typescript #115
base: main
Are you sure you want to change the base?
Conversation
So, before I figure out how tests are setup, #[derive(Debug, Deserialize, Serialize)]
#[typeshare]
pub struct Foo {
pub value: String,
}
#[derive(Debug, Deserialize, Serialize)]
#[typeshare]
pub struct Bar {
pub value: String,
}
#[derive(Debug, Deserialize, Serialize)]
#[typeshare]
pub struct Dummy {
/// generates a normal nested definition
pub foo: Foo,
#[serde(flatten)]
/// generates a flattened definition
pub bar: Bar,
} then typeshare . --lang=typescript --output-file=definitions.ts` becomes export interface Foo {
value: string;
}
export interface Bar {
value: string;
}
export interface Dummy extends Bar {
/** generates a normal nested definition */
foo: Foo;
} It also does not affect the other languages' implementations for typeshare . --lang=swift --output-file=definitions.swift A workaround could be to allow the consumer to define a blank #[derive(Debug, Deserialize, Serialize)]
#[typeshare]
pub struct Dummy {
/// generates a normal nested definition
pub foo: Foo,
#[cfg_attr(feature = "typescript", serde(flatten)])] // <--- this line
/// generates a flattened definition
pub bar: Bar,
} But yes ultimately it's not super ergonomic, so looking for your feedback :) |
Thanks for the PR! I'll give it a review next week |
cc @Lucretiel :) |
Sorry for the delay, reviewing now. really like the idea of using inheritance to solve this, but I'm concerned that this solution won't have an equivalent in languages that don't have inheritance (like Go), or that do but for which it's an unusual pattern (like Swift). I'll give it a review as written but I'll also do some discussion with the typeshare team at our next team meeting. |
@@ -78,7 +78,7 @@ pub enum ParseError { | |||
} | |||
|
|||
/// Parse the given Rust source string into `ParsedData`. | |||
pub fn parse(input: &str) -> Result<ParsedData, ParseError> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
supports_flatten
shouldn't be something the parser needs to worry about; it should unconditionally emit the fully parsed data (including #[serde(flatten)]
attributes), and then that parsed data can be rejected by individual languages when the output is generated, if necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds fair, but concretely just wondering how you would see it implemented.
Alright! I understand your concern, please keep me posted in case I miss the discussion ! 👌 |
This PR concretizes #114.
I haven't added tests, yet.