How do you make use of `value class`es in your dat...

# getting-started

[Chris Fillmore]

How do you make use of `value class`es in your data model?

I have some value class types for various data model id values in my app. They are all uuid strings underneath. My app also deals with e-commerce stuff via a graphql backend, and I’ve asked the backend dev to provide a custom scalar for a value that represents a discount code.

I am unsure how far to take this idea. What is the use case for, say, String, when every value has some additional semantics? Sure, an email client might have a messageBody: String. But why not messageBody: MessageBody?

I realize this question is somewhat language-agnostic, but I am thinking about it specifically in the context of my Kotlin app, so I hope it is appropriate for this channel. I appreciate any opinions here.

[mbonnin]

If the next function that is going to take your MessageBody is Text(String) then there's no need to introduce the value class

[mbonnin]

But if you have more functions that deals with MessageBody (MessageBody.toHtml(), MessageBody.toMarkdown() , etc...) then I guess why not

[mbonnin]

To your graphql point, not all languages have the same facilities as Kotlin for dealing with value classes so there's a high chance your graphql server will be the minimal common denominator between all your platforms, i.e. (String, Int, Float and a few more)

[Chris Fillmore]

Yeah my backend dev is reluctant to take the idea very far and I think I see his point

[mbonnin]

Also, until very recently, there was no way to know how graphql custom scalars would be transmitted over the wire without asking your backend dev. It's now possible with @specifiedBy but every client needs to honour that so it's a lot more work compared to just letting your graphql framework do the serialization/deserialization to/from standard types

[Saharath Kleips]

I agree with the points here - for me it’s just about what value attaching extra details to the type provides. Things like “can I make assumptions about this type now because it’s not just a string”. Like for your id example, is it valuable to know that “id” isn’t just a string but specifically a uuid? Perhaps 🤷 The message body for me as well feels like a similar mental calculation can be made. Is a message body just a string or is should it be MessageBody because I can make some sort of meaningful assumption about its contents?

I think in terms of GraphQL, date time is a good example? You’re probably serializing it as a string (I suppose it could be an int as well) and being able to assert and make assumptions about its format has a lot of value (imo).

As someone who owns a graphql server, an over abundance of custom scalars can be overwhelming and intimidating for clients trying to onboard to the API, especially to those who aren’t familiar with graphql… But for instance our graphql api returns a custom scalar for page cursors and accepts cursors as input values - which can intuitively indicate to a developer that the two values are related.

But I think overall restricting the type just depends on when and where it makes sense. Perhaps it doesn’t make sense for the GraphQL API to have a custom scalar for a discount code, but maybe you want to treat it as such within your own use case?

[Chris Fillmore]

If the next function that is going to take your MessageBody is Text(String) then there’s no need to introduce the value class

This is a good point. I suppose the difference here between that and a domain model id is that I’m likely to use the id without it ever being converted to a string.

Thanks for the feedback so far, this actually clarifies a lot for me