This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-10-30
Channels
- # announcements (15)
- # beginners (143)
- # boot (2)
- # calva (48)
- # cider (93)
- # cljsrn (2)
- # clojure (127)
- # clojure-europe (3)
- # clojure-italy (8)
- # clojure-losangeles (8)
- # clojure-nl (10)
- # clojure-spec (67)
- # clojure-uk (51)
- # clojurescript (20)
- # cursive (9)
- # data-science (2)
- # datomic (10)
- # duct (13)
- # figwheel-main (1)
- # fulcro (74)
- # instaparse (10)
- # jobs (3)
- # joker (8)
- # juxt (4)
- # lumo (1)
- # malli (11)
- # nrepl (3)
- # off-topic (4)
- # pathom (5)
- # pedestal (6)
- # planck (5)
- # re-frame (18)
- # reagent (5)
- # reitit (17)
- # shadow-cljs (165)
- # sql (30)
- # vim (12)
- # xtdb (6)
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.
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))
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
.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
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
.
Quick post about deploying CojureScript to a webserver https://betweentwoparens.com/deploy-clojurescript-on-nginx 🎉
This week on http://clojurescriptpodcast.com we are talking to @roman.bataev about Joker - Small #clojure interpreter and linter
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
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.
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.