Enhanced enum support and types about tsync HOT 8 OPEN

Oh, good idea! Here's the current output:

export interface AppleData {
  crunchy: boolean;
}

export interface BananaData {
  size: number;
}

export interface CarrotData {
  color: string;
}

export type Fruit =
  | { "Apple": AppleData }
  | { "Banana": BananaData }
  | { "Carrot": CarrotData };

The current "problems" with this are:

• You can't type narrow. Because there's no discriminant like "kind", you can't do something like checking which variant it is and then having type-safe access to the internal data
• It's an anonymous type, so for typescript functions that take a certain variant, you either have to manually create a wrapper type, or have a very long inline type (code duplication)
• No const support (this probably won't affect everyone, but I only use const enums in my frontend code, because it maps from my data definitions and database in a more ergonomic way - also more performant)
• Doesn't provide an enum of all the various discriminants, which can also be useful in frontend code

from tsync.

just for reference, could you add what tsync currently does for the provided case?

from tsync.

Also, perhaps rather than changing the default behavior, this should just be another supported option? Because this would be a breaking change, in that enums would be converted in a different way. Basically, instead of inlining the variant data, it would wrap it in a { kind, data } sort of thing, to allow type narrowing and give each variant its own type

from tsync.

Can you try using #[serde(flatten)], maybe that gives you something closer to what you're looking for..

Make sure you're using the latest version

from tsync.

See 2141be7

from tsync.

@AnthonyMichaelTDM What exactly am I supposed to be annotating with #[serde(flatten)]? Sorry, I am looking at the example now, and maybe I should be using #[serde(tag = "kind")] or something? That seems to theoretically get me to an output structure I'm moreso looking for (except, it's still stringly typed rather than using a const enum). Regardless, it doesn't seem to be working. Am I doing something wrong?

Cargo.toml:

[package]
name = "askjdhaskd"
version = "0.1.0"
edition = "2021"

[dependencies]
tsync = { git = "https://github.com/Wulf/tsync.git", branch = "main" }
serde_repr = "0.1"
serde = { version = "1.0", features = ["derive"] }

Input:

use std::path::PathBuf;
use tsync::tsync;
use serde::Serialize;

#[tsync]
#[derive(Serialize)]
struct AppleData {
  crunchy: bool
}

#[tsync]
#[derive(Serialize)]
struct BananaData {
  size: i32
}

#[tsync]
#[derive(Serialize)]
struct CarrotData {
  color: String
}

#[tsync]
#[derive(Serialize)]
#[serde(tag = "kind")]
enum Fruit {
  #[serde(rename = "apple")]
  Apple(AppleData),
  #[serde(rename = "banana")]
  Banana(BananaData),
  #[serde(rename = "carrot")]
  Carrot(CarrotData),
}

fn main() {
  let inputs = vec![PathBuf::from("./")];
  let output = PathBuf::from("../frontend/src/types/rust.ts");

  tsync::generate_typescript_defs(inputs, output, false, true);
}

Output:

/* This file is generated and managed by tsync */

export interface AppleData {
  crunchy: boolean;
}

export interface BananaData {
  size: number;
}

export interface CarrotData {
  color: string;
}

export type Fruit =;

Fruit just seems to have an empty type?

from tsync.

huh... that's odd

from tsync.

Fruit just seems to have an empty type?

Yeah, this just isn't implemented (see our tests for enum).

Here's the relevant section in the code:
https://github.com/Wulf/tsync/blob/main/src/to_typescript/enums.rs#L226-L229

I pushed a fix that should help with the other cases though.

Regarding usage in the frontend though, I completely agree. If you don't have time to implement the above ^, you can try changing tuple enums to a struct enum with a field:

#[tsync]
enum Fruit {
  Carrot { data: CarrotData },
}

(I see your points about this here though)

That should hopefully get you a bit closer to what you want to achieve. Otherwise, I would love a PR! I think the original author (huge thanks to @AravindPrabhs 🙌 ) didn't need this case.

from tsync.