Fork me on GitHub
#announcements
<
2019-10-30
>
kwladyka11:10:41

I wrote an article about ClojureScript form validation using spec: https://clojure.wladyka.eu/posts/form-validation/ This article is also a solution for Clojure backend API to respond with human readable errors. --- I encourage to try my library for ClojureScript form validation using spec https://github.com/kwladyka/form-validator-cljs Here is a demo https://kwladyka.github.io/form-validator-cljs/ --- Please give me feedback if you like / dislike it and what I can do better for you.

kenny14:10:11

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

kwladyka15:10:28

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

kwladyka15:10:16

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))
In library which I made you can use one global spec, which is the whole form and you can additionally define spec for each map key {:password-repeat [password-repeat? ::spec-key]} So here you can set ::spec-key additionaly besides of ::form.

kwladyka16:10:04

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

niwinz17:10:09

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

olivergeorge21:10:19

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}))

kenny21:10:51

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.

tkjone13:10:02

Quick post about deploying CojureScript to a webserver https://betweentwoparens.com/deploy-clojurescript-on-nginx πŸŽ‰

jacek.schae18:10:30

This week on http://clojurescriptpodcast.com we are talking to @roman.bataev about Joker - Small #clojure interpreter and linter

tasos0119:10:39

First public release. Helpful if you come from go-lang and want to try clojure, or if you work on Windows: https://github.com/tasosx/tools4clj

aviflax20:10:12

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Β’

tasos0121:10:32

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.

aviflax15:10:52

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.

borkdude20:10:11

Rewrote the parser configuration options for edamame, a configurable EDN parser which attaches location metadata to values. Examples: https://github.com/borkdude/edamame/blob/master/README.md#parser-options API docs: https://cljdoc.org/d/borkdude/edamame/0.0.8-alpha.4/api/edamame.core 100% backwards compatible with the previous options, which have now become undocumented.