I have a question about Re-frisk. Is there a reason why enable-re-frisk! is called after dispatch-sync in the code in the README here: https://github.com/flexsurfer/re-frisk#web-applications-with-re-frame

cc @andre

i think no

you can enable it once in any place

ok

better to call it in dev ns

yes of course

Since there is no special reason to put it in between, it might be more obvious to call it before calling re-frame’s dispatch-sync in the README?

Hey! I just started using re-frame as the client side data store in my web app, so this might be a really basic question - what is considered a good practice: having a small set of events which accept fn to do the actual change on the reframe-app-db or having a large number of events each of which cater to the smallest granularity of change?

To give a more concrete example lets say we have a number of input forms on my web page each of which correspond to a key in the app-db. So the question boils down to - should I have one generic event which takes in an update-fn and some param to identify the input field being updated or have specific events for each of the input field?

@udit I’ve used that approach where it makes sense

@borkdude my apprehension of using the generic event approach was that the value dispatched would be a fn closed over the actual value thereby reducing the visibility while debugging. Are there other downsides to that approach that I should be aware of?

@udit I’d say just try and re-factor if it doesn’t work out

Heh. I did that already and it’s working fine. But I vaguely remember reading it somewhere in the re-frame docs that events should be dispatched with values, so I refactored to have multiple events, which works but is more verbose imo.

But if there aren’t any red flags or caveats that I should be aware of while following the generic event approach I would go back to the previous implementation. Thanks!

Maybe you could post some snippets of what you have right now

It looks somewhat like this @borkdude ^

Looks fine to me. Doesn’t seem hard to debug imho.

When you have different things to dispatch based on the fields it makes sense to factor out events

@udit I think your abstracted mutation that puts app db paths into the view is the reciprocal of this warning to avoid doing that with the subscriptions side: https://github.com/Day8/re-frame/blob/master/docs/SubscriptionsCleanup.md#a-final-faq

@udit or is that (add-wand) not in the view?

(reg-sub 
   :extract-any-path
   (fn [db path]
     (get-in db path))

@souenzzo hehe

it's just so tempting to do that, right? But then you might as well just get-in from the state atom itself

@udit it might also be a sign of a poorly designed db schema. for example, maybe accessories should be more universal, rather than a different handler for each character class. or the handler could look up the character class and then add the [:magician] at the beginning. Then you'd have something more like (rf/reg-event-db ::accessories-update :wand #(new-wand)) which could work for a warrior class: (rf/reg-event-db ::accessories-update :axe #(new-axe))... ?

Then again, that (new-wand) function needs to live somewhere, and probably not in the view, so you could just have (rf/dispatch ::events/accessories-update :new-wand) in the view and handler would call the (new-wand).

@udit I would definitely recommend a larger number of specific subscriptions and event handlers over a smaller number. Regardless of this choice, you should almost never pass functions as values in your events. Passing data is much much better for debuggability and observability purposes

Hey all, anyone had experience with ring-anti-forgery and re-frame-http-fx?

we haven't, but would be interested in seeing what you come up with

happy to take a PR to make it easier to use in re-frame-http-fx too