Fork me on GitHub
Drew Verlee13:09:18

How would I apply an interceptor to all handlers? E.g the built in debug handler on every event. I see I can add them to individual handlers.


There are global interceptors.

Drew Verlee15:09:41

Ty Ty. I thought i looked at everything related to interceptors 🙂


Is there a drag-and-drop library/solution/component for re-frame or reagent?


FWIW there are for React and you can use them via interop.

☝️ 2

An example repo from about a year ago that was a naive (almost a literal translation from Javascript to Clojurescript) implementation using : Don’t know how crusty it is at this point, but its a data point.

Oliver George23:09:18

This is mostly an observation about a blind spot. I've had a spate of bugs recently related to re-frame plumbing. Specific cases 1. Dispatching to a handler which isn't registered 2. Incorrect registration: using reg-event-fx for a handler returning db 3. Incorrect registration: using reg-event-db for a handler returning fx  A related issue is picking up when a view's dispatch call is incorrect. For commonly used handlers it's picked up quickly through gross dysfunction of core features. For infrequently used handlers it doesn't get picked up. Result is less confidence with refactoring work.  I've added sentry logging for re-frame warnings and errors so that we get error reports from production.  That will pick up two cases ◦ case 1) reports missing handler ◦ case 2) indirectly picks up incorrect registration return type is interpreted as a bunch of fx actions  I've added a global interceptor to check that a flag is present in app-db after each handler. That should pick up case 3 since it's a unique key. Unit tests of the handlers don't help here unless you involve all the re-frame plumbing in the test. As a thought exercise I wonder how re-frame registration could be made smarter.  Something which could detect bad plumbing. Off the top of my head... • Could handler metadata be used to differentiate handler types (db vs fx). • Could spec registry be checked to look for fn signature during registration ◦ Does handler fspec expect or return either a :db or :fx key? Must be an event-fx handler. •  Could kondo pick up these or similar cases ◦ Dispatching to event-id which isn't registered ◦ Dispatching event-v which doesn't match handler signature I can't decide if a strongly typed language would help with the issue given registration aims to decouple but presumably there are ways to leverage types across these types of boundaries.


we have a macro that looks like this


(defevent user-did-thing
  [arg-1 arg-2]
  (fn [{:keys [db]}]
    {:db (... db arg-1 arg-2 ...)
     :fx (... make fx vector ...)}))


it makes a constant for the event name

(defn event:user-did-thing ::user-did-thing)
a function to call that will construct the event vector
(defn user-did-thing [arg-1 arg-2] [event:user-did-thing arg-1 arg-2])
a handler function
(defn handler:user-did-thing ...)
and the call to register the handler
(rf/reg-event-fx event:user-did-thing handler:user-did-thing)


so we never dispatch to a handler which isn't registered (1) since its made via a function call which the compiler will complain about


and we never confuse db handlers and fx handlers because we always use fx handlers (2, 3)


so instead of detecting bad plumbing we just do all the plumbing atomically, if that makes sense


supporting this style kinda necessitated rewriting some helper libs like http-xhrio to support functions for callbacks, but so far its paid off pretty well relative to the amount of effort


@olivergeorge I have a feeling like someone has already done this: using clojure-lsp to statically analyze a re-frame codebase looking for registrations and dispatches, and finding mismatches.

🤞 2

Maybe @borkdude can remember?