I have a data class which looks like this: ```/** ...
# ktor
g
I have a data class which looks like this:
Copy code
/**
 * Represents a single list, which can contain categories to organize list items in it
 */
@Serializable
data class ListDto(
    @Contextual @SerialName("_id") val id: String = ObjectId().toHexString(),
    val user_id: String,
    var name: String,
    val categories: MutableList<CategoryDto>,
    // TODO: types do be defined
    var icon: String,
    var color: String
)
I want the user to create a new List from the frontend so I will need to receive the list data in my ktor put route
Copy code
route("/lists") {
            get {
                // Returns all lists
            }

            put {
               // Need to receive the list data here but obviously it doesn't have an id yet
            }
The issue is that when the user wants to create a list it will not send the list id too, 'cause that will be generated on the server after receiving the list properties like name, categories, etc... Isn't there a way to reuse the ListDto data class but fill the id variable dynamically?
Uhm I think the
= ObjectId().toHexString()
already does it for the id, but that about the
user_id
for example
a
probably a better question for #serialization but i think the only option here is to either use a default argument or create a custom serializer
g
Why the custom serializer?
a
It's just another way you could implement the logic. It's probably not the best way to do it. Another choice would be to make the property nullable
g
Making it nullable would make the dev experience far worse imo
I could just create another data class for the received data even tho that's what I wanted to avoid
a
You might find something useful in here which might make using two separate classes a little nicer https://github.com/Kotlin/kotlinx.serialization/blob/master/docs/polymorphism.md
Maybe the client-side class could inherit from the server-side class and set the undesired property to
@Transient
g
The client-side is flutter xD
So not possible rn
a
Ohhhh I see. I thought you were reusing the same code for client and server. I think the principle still applies if it's all on the server, just instead of client and server, it's incoming and outgoing
g
Uhmm let me check that Transient
a
you could also maybe override it with a default argument in the subclass. or don't listen to me; i'm just some guy who doesn't really know what he's talking about
g
Me neither