Pass details from request in `on-success` and `on-error`

[danielcompton]

It's often useful to have things like status codes, headers, e.t.c. even in successful responses, e.g. when getting a 201 with a Location header. Currently we only return the body of the response. There's a few things to think about here:

• Do we always return the full details, or is it an additional flag?
• Do we return the raw Xhr object? They are designed to be reused and recycled, so this could be a problem if we ever did this in the future?
• Do we return a map with :response and :xhr, or extract the useful keys from the Xhr and put them in the map?

[gabrielnau]

Indeed that would be needed ! Here are my 2 cents:

• Additional flag would allow easier update of the lib when already having lots of code using the default behaviour (although I'm not in that case, I had to build a very tiny wrapper around :http-xhrio)
• If we extract useful keys from the Xhr, it does solve the reused Xhr issue right ? Seems like the less deceptive thing to do.

[mangr3n]

I'm having this issue currently. Some of the data I need is in response headers. The third option to provide :xhr as a map of the content :status, :headers, :response-raw. would solve all of my problems.

[pablobcb]

+1 on this, need details inside the http request

[achikin]

Any updates on this?

[mike-thompson-day8]

Please see the "Tip" at the bottom of the README https://github.com/Day8/re-frame-http-fx#tip

[superstructor]

Turns out there are at least four different types of situations in which one may receive a value in an event handler:

1. :on-success with a body parse error
2. :on-success with a parsable body
3. :on-failure with a body parse error
4. :on-failure with a parsable body

Up to now the behavior has been:

• None received headers.
• Only (2.) does not receive status. It is just the body itself.
• (3.) has a weird bug where it replaces the HTTP status text with the parse error text.

To fix this properly to return a uniform value a breaking change is needed. The value will always be a map of the shape:

{:uri ""
 :last-method ""
 :headers {:location ""}
 :status 201
 :status-text ""
 :response {:answer 42}}

~0.2.0 will~ 0.3.0 might be released with :http-xhrio deprecated and a new fx handler called :http/req.

Other new fx handlers ~will~ might be added for :http/defaults (#32 / #4) and :http/abort (#3).

[hoxu]

0.2.0 and 0.2.1 seem to be released, but somewhat confusingly the 0.2.0 goal is still open, so this one hasn't made it to release either.

[superstructor]

@hoxu Thanks for pointing out the inaccuracy with milestones vs actual releases. I have fixed that.

Initial intent was to release this and some other changes as 0.2.0 but we ended up doing a lot of work on experimental alternatives re-frame-http-fx-alpha / http-fx-alpha-example and the simpler spin off from that work re-frame-fetch-fx.

None of those are canonical re-frame replacements for this project yet.

http-fx-alpha is what it says in the name, a bigger experiment for which we have not fully resolved some design problems such as how to handle state machines or behavior trees in re-frame in general.

fetch-fx is the modern js/fetch only work pulled out of http-fx-alpha without all the experimental other new ideas like state machines, so its very stable today as long as the browser has js/fetch support but not an officially blessed API as the future of re-frame's official offerings.

Lastly, we're not working on this project here at the moment, but I will look at and might accept pull requests that don't break backwards compatibility.

[ClemRz]

Ther is a way to pass through the repsonse headers. For that you'll need to write a custom response-format:

...
:http-xhrio {... :response-format {:read (fn [xhrio] {:body obtain-the-body-from-xhrio :headers obtain-some-headers-from-xhrio})} ...}
...

You can look at ajax.json/make-json-response-format for an example of :read fn. To get a header you can use ajax.protocols/-get-response-header for instance.

If the call succeeds you should get a map corresponding to what returned the fn you declared in :read.

I know this is not the easiest implementation ever but it does the trick.

I also used it to set custom request parameters like responseType and such:

(defn array-buffer-response-format
  []
  {:description "Custom array-buffer format"
   :type :arraybuffer ;; sets the responseType param of the request to "arraybuffer"
   :read (fn [xhrio] {:array-buffer (-body xhrio)
                      :content-disposition (-get-response-header xhrio "Content-Disposition")})})

For more info, read https://github.com/JulianBirch/cljs-ajax/blob/master/docs/formats.md

I hope this can help.

[scarytom]

FYI, some relevant discussion on Clojurian's Slack. The conclusion was that one should probably opt for re-frame-fetch-fx over re-frame-http-fx these days.