Return an Http.Response a for every request
#36
Conversation
Sometimes you need the headers. Sometimes you need the status code. Since those values are always available for every request, we can return them by default. If you don't need the response, it's straight forward to remove it. E.g. If before you had something like: ``` Http.send handleResult request ``` And you wanted to get rid of the request, you would now do: ``` Http.send (handleResult << Result.map .body) request ```
|
@mattjbray Any thoughts? |
|
Thanks for the PR! I think we could definitely have an option to switch on this behaviour. That would only allow users to enable/disable it for their entire API though. Alternatively, we could generate a function returning a |
|
Selectively generating the response works. Though at that point, it'd be even nicer if we could just pluck the known headers out and throw them in a record: type API
= "foo"
:> Capture "id" Integer
:> RequestBody Foo
:> Post '[JSON] (Headers '[Header "Last-Modified" UTCTime, Header "Link" Text, Header "Location" URI] Foo)postFoo : Int -> Foo -> Http.Request ({ lastModified : Date, link : String, location : String }, Foo)Or something. |
|
I will say though, having used |
|
I've merged #74 that achieves similar goals with the new elm-bridge, going to close this PR as it's outdated. |
I could have sworn there was an issue already, but I guess not.
In any case, with the way the code is generated now, we have no way of ever getting access to the response. But sometimes the header is useful. Currently, the only time you get access to the response body is if the request failed. If we just always return
Response a, then users of this package can decide if they care or not about the response.This is a breaking change. If this seems like too intrusive of a move, would you accept a second function that always made a
Response a? If not a second function, what about options?