Clojurians Log v2

Don't dispatch multiple times. Instead, combine those events into one and dispatch only the new event.

:fx [[:dispatch [...]] [:dispatch [...]]] fx dispatches are ordered iirc (= add an intermediate event as suggested above)

If a request fails, then it's not :on-success that is triggered.

You can use on-success and on-failure and pass data. I assume you want data to be available in your on-failure method (as your request fails)? Works for POST as well.

(reg-event-fx
  :some-useful-get
  (fn [db [_ data]]
    {:http-xhrio {:method          :get
                  :uri             your-url
                  :timeout         5000
                  :response-format (ajax/json-response-format {:keywords? true})
                  :on-success      [:your-success-method data]
                  :on-failure      [:your-failure-method data]}})))

(reg-event-db
  :your-success-method
  (fn [db [_ data result]]
    ....)

(reg-event-db
  :your-failure-method
  (fn [db [_ data result]]
    ....)

^ just pass data into the :your-failure-method event vector as well. :)

haha, oops :-)

@p-himik The problem is my on-success is being fired, which I can see because it takes the item being submitted out of the "shopping basket". And the printlns in the function also get called.

So I think it's a problem with the service I'm talking to - the service is probably returning a 200 with an error code in JSON.

(re-frame/reg-event-db ::upload-to-heedy-success store-basket-interceptor  
 (fn [db [x response]]                                                    
  (println "upload success " response)                                   
  (update-in db [:basket] dissoc response)                               
  ))

When it is set up this way with http-xhiro: :on-success [::upload-to-heedy-success] I get a response of "{:result ok}"

So either it's the backend that's to blame for a wrong code, or your code for not handling the response correctly (some APIs always respond with HTTP 200 but pass the error in the body). Both cases have nothing to do with re-frame.

But when I set it up this way: :on-success [::upload-to-heedy-success date] I get the date only upload success 1701745448671

This does. I should be able to get my date and the response body.

What is store-basket-interceptor?

It puts the basket map into local storage

(def store-basket-interceptor             
 (re-frame/after db/basket->local-store))

I know that "{:result ok}" is what the Heedy API returns on a successful upload.

reg-event-db without the trim-v interceptor always passes the event ID as the first item of the second argument to the event handler. That would be x in your example. When you use [::upload-to-heedy-success], response will indeed be the response. When you use [::upload-to-heedy-success date], response will always be date since you don't destructure the vector to get its third item.

Eh? From the http-fx docs it reads like the date should be in the response.

Where?

> These event vectors will be dispatched (`result` is conj-ed to the end) making all encoded values AND the result available to the handlers.

I don't see it talking about the response at all. result is probably the response, yes. But where does it say that whatever else you pass to the event vector will end up being a part of the result value? Even if it did say so, how could it possibly be true? Suppose the server answers with "hello" - how can you make an arbitrary date a part of that value?

The line quoted by you says explicitly: result is conj-ed to the end. So if you specify :on-success as [:evt], then on success (conj [:evt] response) will be dispatched. If you specify it as [:evt date], then (conj [:evt date] response) will be dispatched.

Hmmm I kind of see. This worked:

(fn [db [_ date response]]                 
 (println "upload success " date response)

Thank you 🙂 I was missing something.

the code example shows this destructuring ;-)

Which code example?

the third message in this thread?

Ah. I missed that facepalm