Fork me on GitHub
#re-frame
<
2018-03-20
>
ericnormand12:03:13

also @lwhorton, you say it's top down, but I think it is bottom up. Go to the very bottom. The individual pieces of data and the operations on those data. Most people start somewhere in the middle, e.g., everything this current view needs.

ericnormand12:03:29

true bottom-up, where you break it down as far as it can go, is what you're looking for

lwhorton13:03:03

Is there a generally accepted convention for defining default-interceptors for all fx/db handlers? for example, I always want trim-v on everything, and usually a spec validator too. normally I would wrap the re-frame lib into my own my-ns.re-frame and redefine some fns in that namespace, but it seems kind of heavy-handed

nenadalm20:03:52

The problem is that the interceptors are hardcoded in the functions: - https://github.com/Day8/re-frame/blob/master/src/re_frame/core.cljc#L84 - https://github.com/Day8/re-frame/blob/master/src/re_frame/core.cljc#L101 It would be probably better, if there was some var default-interceptors which would be used by these functions and could be overwritten by the app.

joshkh15:03:32

^ also curious about this!

joshkh16:03:36

you could make your own reg-event-* function:

(defn reg-event-xtreme [id handler] (reg-event-db id (your-default-interceptor) handler))

joshkh16:03:45

but i see where applying interceptors system wide would be useful, like having certain ones in a debug environment

danielcompton21:03:29

@lwhorton you could make your own re-frame handlers, or make a common def for the middleware you want and apply it in each of your event handlers

nenadalm05:03:31

yes, that is useful for new apps. For existing apps, all registrations have to be replaced.

lwhorton22:03:48

^ that’s what I did, thanks guys