snake_case in Zod and/or Class

I am working with a Python Django back-end. It'd be most efficient to mimic the Django DB model fields in Zod to make communicating with the API more accessible. e.g. in Django I might have a Product.long_description field. Now, in my Next app I have a class Product with some useful getter methods for example. Ideally, I would have a Product.longDescription in TS To make creating and reading API responses <> Product classes more efficient, it'd be most efficient to use snake_case so I don't need to worry about re-assigning every API response field to a camelCase variable/property. Basically my question is. Is it, in this case, really a sin to use snake_case in TS?
8 Replies
Keef
Keef12mo ago
You won't see snake case in ts code bases atleast from what I've seen the common convention is to do camelcase. This might be helpful for you https://github.com/colinhacks/zod/issues/486 But you might also be able to change how python builds the object. I consume a different language web api in our frontend and I just make sure that the json I deliver is already camel cased. Its rust but serde makes it extremely easy to this. Maybe this could also be an option for you?
// Example snippet from codebase
#[derive(Debug, Default, Serialize, Deserialize)]
// this does the magic
#[serde(rename_all = "camelCase")]
pub struct Paginated<T> {
pub list: Vec<T>,
#[serde(skip_serializing_if = "Option::is_none")]
pub next_offset: Option<i64>,
#[serde(skip_serializing_if = "Option::is_none")]
pub has_more: Option<bool>,
}

// JSON OUTPUT:
/*
{
"list": [],
"nextOffset": 1,
"hasMore": false
}

*/
// Example snippet from codebase
#[derive(Debug, Default, Serialize, Deserialize)]
// this does the magic
#[serde(rename_all = "camelCase")]
pub struct Paginated<T> {
pub list: Vec<T>,
#[serde(skip_serializing_if = "Option::is_none")]
pub next_offset: Option<i64>,
#[serde(skip_serializing_if = "Option::is_none")]
pub has_more: Option<bool>,
}

// JSON OUTPUT:
/*
{
"list": [],
"nextOffset": 1,
"hasMore": false
}

*/
GitHub
Allow defining a different key into the final destination object af...
Right now zod is becoming more and more an integral part of all my projects, however, there's still a pretty common use case that doesn't have a direct mapping in zod, basically, allowing t...
Keef
Keef12mo ago
nyx do you see my beautiful propaganda its subtle
Neto
Neto12mo ago
you should follow a rule like that if its the starndard on the codebase if the codebase is using camel case, use it if the codebase is using snake case, use it either way you should sanitize on both culture is very amazing
Keef
Keef12mo ago
offtopic but macros in general are really chefskiss
Neto
Neto12mo ago
macros are witchery is close to write state machines
niels
niels12mo ago
Im not sure what the 'correct' answer is in that GitHub issue
Keef
Keef12mo ago
Its not a thing zod will be implementing But you can see some of the discussion around how people are doing it "zod rename keys" is what you can google
dan
dan12mo ago
no, its just not commonly used. As long as the naming is consistant people generally don't care. oh ok discord show me the messages after lol
Want results from more Discord servers?
Add your server
More Posts