Theo's Typesafe Cult•2y ago

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•2y 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•2y ago

nyx do you see my beautiful propaganda its subtle

Neto•2y 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•2y ago

offtopic but macros in general are really chefskiss

Neto•2y ago

macros are witchery is close to write state machines

nielsOP•2y ago

Im not sure what the 'correct' answer is in that GitHub issue

Keef•2y 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•2y 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

Gaming

Programming

snake_case in Zod and/or Class