First of all, thank you for your work in creating this library!
I've hit a small snag: I have a newtype that is used as a capture parameter in an endpoint:
newtype Id = Id Int32 deriving ( Eq, Generic, Show, FromHttpApiData)
type API = Capture "id" Id :> ReqBody '[ JSON] Resource :> Put '[ JSON] NoContent
The generated API function generates a URL that looks like this: /Id%206, because it whereas servant's default decoder for this newtype expects a URL that simply reads /6. It looks like this happens when the Elm version of the newtype (type Id = Id Int) is passed through toString.
Is there something I can do to make this work, short of getting rid of getting rid of the newtype?
One potential avenue: We also generate an elm encodeId : Int -> Json.Encode.Value function. If for encoding the parameter in the query string we'd call that function first, then encode the Json value into a string it looks like we would generate the correct URI.
First of all, thank you for your work in creating this library!
I've hit a small snag: I have a newtype that is used as a capture parameter in an endpoint:
The generated API function generates a URL that looks like this:
/Id%206, because it whereas servant's default decoder for this newtype expects a URL that simply reads/6. It looks like this happens when the Elm version of the newtype (type Id = Id Int) is passed throughtoString.Is there something I can do to make this work, short of getting rid of getting rid of the newtype?
One potential avenue: We also generate an elm
encodeId : Int -> Json.Encode.Valuefunction. If for encoding the parameter in the query string we'd call that function first, then encode the Json value into a string it looks like we would generate the correct URI.