Fork me on GitHub

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.


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


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 and redefine some fns in that namespace, but it seems kind of heavy-handed


The problem is that the interceptors are hardcoded in the functions: - - 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.


^ also curious about this!


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

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


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


@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


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


^ that’s what I did, thanks guys