Can you define an event with just a chain of interceptors and no handler?

@caleb.macdonaldblack No, but you can create a do-nothing handler:

(reg-event-db 
    :event-id 
    [a long list of interceptors]
   (fn [db _] db))      ;; <--- dummy, do nothing  handler ???

Actually, better to do this:

(reg-event-ctx       ;; <-- rarely used event registration mechanism
    :event-id 
   [a long list of interceptors]
   identity)         ;;  <-- just return the `context` given 

Thanks, that’s exactly what we were looking for.

shameless plug: I’ve written an article (https://medium.com/@kirill.ishanov/building-forms-with-re-frame-and-clojure-spec-6cf1df8a114d) and a corresponding sample application (https://kishanov.github.io/re-frame-spec-forms-example) about building forms using re-frame and clojure.spec (no frameworks have been created)

@kishanov thanks for sharing, excited to read this!

I have some db event handlers that do something stateful like this:

(re-frame/reg-event-db
  :db/initialize-iota
  (fn [db [_ v]]
    (let [state (make-state)]
      (assoc db :state state))))


(re-frame/reg-event-db
 :db/initialize-iota-mam
 (fn [{:keys [state] :as db} _]
   (let [changed-state (change-state state)]
     (stateful-fn changed-state)
     (assoc db :state changed-state)))

@kishanov good read. I'm having a little bit of trouble understanding this paragraph though: >I’ve played with the idea of mapping error messages to s/explain-data while parsing the returned data structure and mapping error messages to different bits of this data structure, but I quickly abandoned this idea cause the resulting code is coupled to spec implementation itself and in real world it’s easier to have a custom error component that is mapped to predicate directly, rather then carrying the complexity of this data analysis to forms controller. I've also used s/explain-data in this way, and it allowed me to map specs to error messages, like this:

(def spec-err-msgs
  { :user/email "Invalid email provided"
    :user/name-length "Username must be between...characters long"
    ...})

I should also include: I had written an interceptor that ran s/explain-data on every input change, and stored it in app-db, so my spec outputs were alongside the values in app-db. These error messages could then be set up as subscriptions.

@cjsauer I’m mostly concerned about the problem of granularity of the error message. Imagine having a spec for password field (our beloved “1 upper case letter, 1 lower case letter, 8 charachters or more, etc.“). It’s easy to have 1 spec which will either have a regex to validate it or will use s/and and s/or to concat multiple specs. I’ve looked at how s/explain-data works for these these specs with conditional branching and didn’t like the complexity of mapping proper error message to each part of the branch

I’m not saying it’s impossible to do it, but it looks like unnecessary complexity to me. after starting to use spec I’ve noticed that the an attempt to have a perfect validation logic in the spec is an excellent way to procrastinate and not proceed with the actual work 🙂

hi, i have a dumb question that i can't seem to find via googling - how do i make a regular link work in re-frame? [:a {:href "" :target "_self"} "GOOGLE"] routes me to / in my router.cljs ... :target "_blank" opens in another tab. if i missed something obvious, i apologize in advance

i started from the re-frame template, fwiw

[re-com/hyperlink-href
   :label "go to google"
   :target "_self"
   :href ""]

welp! i'm not sure what i did, but it fixed itself - sorry for the noise. (i stuck with the re-com method)

a late thanks to @mikerod and @ivanreese

repo for all the code is here: https://github.com/CalebMacdonaldBlack/re-frame-interceptors-demo

Is anybody using devcards with re-frame? Do the two even fit together nicely?

https://github.com/nberger/devcards/blob/iframe/example_src/devdemos/re_frame.cljs

This is the nicest I've seen