Clojurians Log v2

@hiskennyness Can you dispatch the new value in the on-blur handler and then, in the event handler, compare that with the existing value? Ie. I'm assuming the existing value is stored in app-db ? (I fear I'm not understanding something important here)

Hi everyone, I have a question about subs/events: I have a POST event that :on-success dispatches a call to this function:

(re-frame/reg-event-db                   
 :process-response             
 (fn
   [db [_ params response]]
   (let [rows (clj->js (:rows response)) last-row (clj->js (:lastRow response))]
     (-> db
         (assoc :data rows)
         (assoc :last-row last-row))
     (.successCallback ^js params rows last-row)))) ; <-- Am I going to be a wanted man for this?

(defn get-rows
  "I get called when loading the grid and scrolling past every 100 rows until last-row.
   I end up triggering :process-response"
  [params]
  (dispatch [:request-it params]))

There are other solutions but they're much more cumbersome and fragile. I would do the same thing here. Except maybe I'd pass (fn [rows last-row] (.successCallback ^js params rows last-row)) to the event handler, just so it doesn't have to know about the inner workings of params.

Ok, thanks for the information and tip!

I am still learning re-frame, but from what I have understood so far, I would register new effect handler (`reg-fx`) which would call .successCallback and register :process-response as effectfull event handler ( reg-event-fx) and return this new effect. This way :process-response event handler would remain pure and side-effect will be only in effect handler.

Indeed, but in this case .successCallback requires some object to operate on - you will have to pass it in some way (directly or via a closure) either way. Creating an effect just shifts the execution a bit without changing the overall structure. Also, it could be generalized to just :call if you're using a closure.

Purpose of separation of effects to effect handlers is, in my opinion, for easier testing of event handlers, so i would rather pass params to effect handler.

@https://app.slack.com/team/U01D0UM4277 Nit pick: the way you have written that handler will be a problem because it doesn't seem to be returning an updated db @jaroslav.pernica9 is correct, the rightest (TM) way to do it would be to create a effect via reg-fx .

(re-frame/reg-event-db                   
 :process-response             
 (fn
   [db [_ params response]]
   (let [rows (clj->js (:rows response)) last-row (clj->js (:lastRow response))]
     {:db 
       (-> db
         (assoc :data rows)
         (assoc :last-row last-row))
       :your_effect {:params params :rows rows :last-row last-row))))

@mikethompson Thanks for the information and heads up, I'm just starting out and didn't think about the return value ordering in this case, this saved me some headache in trying to figure out why the db wasn't updating 😄

Hello, can someone point me to some documentation/other resource on how to deal with processing a whole form data set in one go when user, for example, clicks a submit button? New at this, not sure how to do correct subscriptions/triggering of events etc in such a case :)

In my forms, I prevent the default submit event and instead make it dispatch an event with all the data.

It's not really re-frame specific - just the dispatch part is.

@danielostling Have a look at real world app demo: https://github.com/jacekschae/conduit