DEV Community 👩‍💻👨‍💻

Discussion on: A type for views

Collapse
 
1hko profile image
1hko • Edited on

I encounter similar issues when decoding JSON responses. The types and fields coming in the response are not a 1:1 mapping of what your program actually needs. Do you use a similar technique there? For example, separate BookPayload, Book and BookView types?

Collapse
 
jwoudenberg profile image
Jasper Woudenberg Author • Edited on

Oh yes, that's a great example! Yeah, we tend to create a type that's very similar to the structure of the JSON we receive through flags or http responses. Then write a transformation functions from those Flags or Backend types to a Model. And when encoding some data to JSON, for example as the body of a request, the same trick can be used there too!

Collapse
 
1hko profile image
1hko

Nice technique. This smells like another one of those things that people (unfairly) criticize Elm (and other FP languages) for because the effective techniques for handling common patterns are very different from those found in languages of the other paradigms. Novices are not likely to discover the technique in their own code writing and therefore their frustrations dealing with a lesser-effective technique are likely to be targeted toward Elm itself; fair or otherwise. I still find it difficult to communicate these subtleties with beginners and wonder how Elm will face these challenges. Maybe I heard it somewhere else, maybe not, but I carry a motto for Elm in my mind that says "it's broken until it's easy for everyone", and maybe another one that says "if it makes things harder, we're not adding it." I'm excited to see how Elm and the community will make better and better abstractions that enable even higher level programming with even less complexity. Thanks for sharing your post.