Interesting approach. This requires you to write your specs always using a s/def, correct? i.e., you cannot use inline functions in an s/and

yes, because you use this (s/def ::email ...) keyword to determine what invalidated the map

another approach is to assign to each input field spec definition seprately instead of using ::form

(-> {:names->value {:email ""
                    :password ""}
     :form-spec ::form
     :names->validators {:email [email-exist?]
                         :password-repeat [password-repeat? ::spec-key]}}
    (form-validator/init-form))

combining 1 spec for whole form and let add additional fn / specs for each form input seems to be fully functional for all you can need

i have used a similar approach in my own projects, nice article!

Using :via as a an error code seems nice. Slight conflation perhaps but quite handy. Here's a quick hack in a prototype I wrote recently, great to see others doing similar things.

(defn problems
  [spec data]
  (for [{:keys [path via val]} (::s/problems (s/explain-data spec data))
        :when (seq path)]
    {:path path :code (last via) :val val}))

For those interested, we do something similar in https://github.com/Provisdom/user-explain. It lets you dispatch on anything in the explain-data problem rather than just the path.

Interesting! The README is solid 👏 One suggestion: in addition to the What is this? section, it’d be helpful if there was also a Why is this? section — i.e. Rationale. Just my 2¢

Thank you for your feedback. 😃 The Why? section existed, but eventually transformed to Is it only for Windows? section, and ease of installation/update that golang offered, the Usage section.

My pleasure. Ah I see, yeah it’s always interesting how docs evolve. You might want to bring back the rationale section. Now that those other sections exist, it can be short and sweet.