Closed joneshf closed 7 months ago
@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 Http.Response a
if the corresponding endpoint is, for example, a Get (Headers '[...] a)
. Would that fit your use-case? (See also #32.)
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 Http.Request (Http.Response a)
for a bit of time, it's actually kind of nice to be able to grab stuff after the fact.
I've merged https://github.com/haskell-servant/servant-elm/pull/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?