You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to support rust_decimal's Decimal type. Depending on configuration, this type can be represented in serde as either a float or a string. This is further complicated by options covering the whole crate or just specific fields. While generating TypeScript types via tsync, I would like to somehow specify which representation to use.
Currently I can create a separate module exclusively for inclusion in tsync and export custom type mappings there, however I would prefer to erase the type entirely.
Alternatively, I can fork the project and and add the additional type to convert_type directly as a global type mapping. This produces results closer to what I want, but requires more work to maintain.
Neither of these solutions would help the per-field case.
I am wondering about adding a field parameter to override types in-line, something like:
Yeah, we definitely need something like this. You've probably noticed the hard-coded types for something like chrono's NaiveDate/Time types... it isn't an ideal solution, but it was a hack that got us this far 😅 .
I would love to see something like added to tsync. I really appreciate your detailed explanation of the problem and approaches you've thought of.
I would like to support rust_decimal's
Decimal
type. Depending on configuration, this type can be represented in serde as either a float or a string. This is further complicated by options covering the whole crate or just specific fields. While generating TypeScript types viatsync
, I would like to somehow specify which representation to use.Currently I can create a separate module exclusively for inclusion in
tsync
and export custom type mappings there, however I would prefer to erase the type entirely.Alternatively, I can fork the project and and add the additional type to
convert_type
directly as a global type mapping. This produces results closer to what I want, but requires more work to maintain.Neither of these solutions would help the per-field case.
I am wondering about adding a field parameter to override types in-line, something like:
The text was updated successfully, but these errors were encountered: