Max, Elm does not support phantom types (to my understanding). What do you have > in mind here? How can phantom types represent relationships? >
Based on my understanding/definition <https://wiki.haskell.org/Phantom_type> of Phantom Types, they are very much possible in Elm. An explanation + conversation over this medium is likely not going to be effective, so I'll just provide 2 links for those interested in how it is that I am making use of this idea. library relation type <https://github.com/john-kelly/elm-postgrest/blob/master/src/PostgRest.elm#L175> and sample usage <https://github.com/john-kelly/elm-postgrest/blob/master/examples/Resources.elm> Interesting. I take it you are generating resource definitions from the > Postgres schema. In my library, the resource's representation (as a type > alias of a record of attributes) is the input to the code gen, the one > thing that is *not* generated. *If* I were to be using codegen, *yes* I would be using the schema of the db table or view. More importantly though, I think there is a slight confusion in what it is that I mean by *Resource Representation**. *I don't claim that my naming is good, but what i mean by Resource Representation is a representation of the shape of the backend/api server on the frontend. Maybe it would be better to refer to this as a Schema? see here <https://github.com/john-kelly/elm-postgrest/blob/master/examples/Resources.elm> for what a "Resource Representation" or "Schema" looks like in the library. This representation serves as the single point in the application where the shape of backend/json api server lives. The representation contains all information related to fields, types of those fields, and relations. As you'll see if you dig into the library, this is how we can build up decoders while building up queries. In the library, the user must still provide how they wish the data received from the server to take form in elm. Whether that is a record or some union type. I think that taking a look at the hello world example <https://github.com/john-kelly/elm-postgrest/blob/master/examples/BasicExample.elm> of the library will make this point clear. And I think one might as well generate encoders and decoders, at least if > not overridden, so that the code one must write by hand (those type > aliases) is as minimal as possible. The api of the library allows one to build up the decoders and encoders *while* building up the query. In postgREST (and the more popular graphql), the user specifies what fields they would like to select from the backend. The idea of the library's api is: "Why not build up the decoder while the user is specifying what fields to select?" The user is not using decode pipeline or the standard json decoder api; the library abstracts this away and does it for you! Anyways, I see now that explanation of this is a bit tricky via email! Especially when definitions for things are so fuzzy! If anyone is interested in chatting about this more -- feel free to pm me on slack @johnkelly -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
