Fork me on GitHub
#re-frame
<
2017-12-10
>
chang07:12:08

Is this idiomatic re-frame?

(do (dispatch [:add-key %])
    (dispatch [:request %]))
Once the user submits a field, I want to automatically make an ajax request to some api.

p-himik07:12:03

@mohamedhayibor I may be wrong, but I don't remember re-frame giving any particular advice on this. You have to do the coupling "user submits a fields -> add key and make request" somewhere. There are two obvious choices - in the view, as in your example, and in the event handlers by creating a new event :submit-field that then uses :dispatch-n effect to dispatch those two events. I would say that the second option is better, since the coupling of particular events to particular effects is already being done in the event handlers. So why propagate it to the views when you can leave all coupling in one place?

p-himik07:12:37

There are blog posts that describe this much better than I just did, but the ones that I've read all suggest the second approach.

lepistane09:12:37

is there a re-frame lib that is used for different components? like i wanted to make tabs because it's needed for dashboard the only thing i could find is https://github.com/Day8/re-com Is there anything i couldn't find? Would any reagent component lib do the job? Are there any that are mobile friendly ?

mikethompson11:12:43

@mohamedhayibor no, that isn't idiomatic. dispatch shouldn't be used to perform "function calls"

Bravi20:12:23

I’m trying to understand when would I use reg-cofx instead of reg-fx. I’m following this: https://github.com/Day8/re-frame/blob/master/docs/Coeffects.md and some other examples I found on the web. they seem to be doing the same thing, or am I missing something?

joelsanchez20:12:42

@bravilogy I use it for injecting local-storage. It's a way of injecting additional dbs. You could inject another atom and it would be a secondary db

mikerod20:12:03

@bravilogy reg-cofx I think overly simplified: is for passing more arguments to your event handler registered via reg-event-fx. reg-fx are “downstream” side-effects that are a result of what is returned by event handlers

mikerod20:12:10

So they are 2 different parts of the pipeline

mikerod20:12:28

I think @joelsanchez has a good example reason for why to use reg-cofx though

Bravi20:12:19

ah so reg-cofx basically registers something that will be received by the event handlers and reg-fx registers something that will be output by them?

Bravi20:12:32

I mean I get the reg-fx part

Bravi20:12:41

actually it makes sense now 😄

mikerod20:12:16

That sounds like a good way to say it to me

Bravi20:12:18

reg-fx is basically a generic way to describe some side effect right? like

(re-frame/reg-fx
 :print-out
 (fn [value]
   (.log js/console value)))

Bravi20:12:43

and then from reg-event-fx I could pass some value to :print-out

joelsanchez20:12:48

real example:

(rf/reg-event-fx
 ::close
 [(rf/inject-cofx :local-storage)]
 (fn [{:keys [db local-storage]}]
   ;; do things with either db or local-storage
   {}
))

Bravi20:12:22

nice, thank you

Bravi20:12:35

I’ll have a go at local storage implementation now

Bravi20:12:30

ok that makes sense now 😄 did a simple

(re-frame/reg-cofx
 :storage
 (fn [cofx _]
   (assoc cofx :storage {:todos {}})))

(re-frame/reg-event-fx
 ::initialize-db
 [(re-frame/inject-cofx :storage)]
 (fn [{:keys [storage]} _]
   {:db (or storage db/default-db)}))

Bravi20:12:57

db/default-db has a few entries so now it doesn’t display anything

Bravi20:12:34

I like the fact that this is not injected in every single event

Bravi20:12:52

automatically

joelsanchez20:12:22

what I still don't know is how to inject a coeffect in a subscription, looks like I can't (and I have to do horrible hacks to work around it)

Bravi20:12:47

in which case would you need to do so?

joelsanchez20:12:39

your component depends on the ::closed? value in local-storage

joelsanchez20:12:56

I need to get ::closed? from local-storage, put it in the db

joelsanchez20:12:03

then subscribe to the db, and then keep both in sync

mikerod20:12:10

@joelsanchez I don’t know of an alternative to that

mikerod20:12:31

I think subscriptions are intended to only be “views” over the “single source of truth - the db” or something

mikerod20:12:48

so maybe it is a violation of principle? hah

joelsanchez20:12:54

it's strange that events can get any coeffect but subscriptions can only get the db coeffect, making the db coeffect special

joelsanchez20:12:49

well if there was a single source of truth, why would we have coeffects?

mikerod20:12:12

I probably am not qualified to weigh in on that yet hah

mikerod20:12:28

I’d need to think about this one a bit. I haven’t ran across that sort of situation yet eithert though.

joelsanchez20:12:47

it's not a very big problem, but I don't understand why it's done this way

mikerod20:12:47

Yeah, I’d certainly like to hear others thoughts on that