Fork me on GitHub
#re-frame
<
2020-10-28
>
greensponge08:10:39

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?
I have a ag-grid-react component that has infinite scrolling enabled and I've hooked this to the event that triggers an internal "get more rows for every 100 rows scrolled":
(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]))
The API for the ag-grid-react component wants me to trigger the successCallback, but I'm not sure where I should do it with re-frame in mind? Is it fine to do it in this way or do I need to trigger more dispatches? I suppose the meta question here is, is this callback considered a side-effect that I need to deal with?

p-himik09:10:38

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.

👍 3
greensponge09:10:40

Ok, thanks for the information and tip!

Jarda Pernica10:10:12

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.

👍 3
p-himik10:10:28

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.

Jarda Pernica11:10:55

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.

mikethompson12:10:15

@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 @U01DDPQE4FM 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))))

👍 3
greensponge14:10:25

@U051MTYAB 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 😄

Daniel Östling21:10:50

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 :)

p-himik22:10:56

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

p-himik22:10:17

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

Daniel Östling06:10:10

Perfect, thanks guys 🙂