re-frame

https://github.com/Day8/re-frame/blob/master/docs/README.md https://github.com/Day8/re-frame/blob/master/docs/External-Resources.md
2020-10-28T03:04:48.257800Z

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

greensponge 2020-10-28T08:42:39.260100Z

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-himik 2020-10-28T09:24:38.260200Z

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.

1πŸ‘
greensponge 2020-10-28T09:54:40.260500Z

Ok, thanks for the information and tip!

Jarda Pernica 2020-10-28T10:12:12.260700Z

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.

1πŸ‘
p-himik 2020-10-28T10:33:28.260900Z

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 Pernica 2020-10-28T11:39:55.261100Z

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.

2020-10-28T12:08:15.261400Z

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

1πŸ‘
greensponge 2020-10-28T14:10:25.261700Z

@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 πŸ˜„

kennytilton 2020-10-28T14:28:50.262100Z

Yep, that is the way we are going. I just had a bug loading the prior value into app-db, and my re-frame is rusty enough that I thought the whole approach was in vain. We spotted the bug and are in good shape now. Thx! @mikethompson

andre 2020-10-28T19:15:39.262300Z

it's better to use :preloads [re-frisk.preload] in your dev config

furiel 2020-10-28T19:54:27.263100Z

@andre Thank you! Preload worked nicely.

Daniel Γ–stling 2020-10-28T21:28:50.265300Z

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-himik 2020-10-28T22:16:56.265400Z

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

p-himik 2020-10-28T22:17:17.265600Z

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

Jarda Pernica 2020-10-28T23:13:40.265800Z

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