This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-19
Channels
- # bangalore-clj (35)
- # beginners (42)
- # boot (89)
- # cider (9)
- # clara (2)
- # cljs-dev (29)
- # cljsjs (3)
- # cljsrn (14)
- # clojars (9)
- # clojure (332)
- # clojure-brasil (1)
- # clojure-dev (5)
- # clojure-italy (4)
- # clojure-russia (36)
- # clojure-spec (38)
- # clojure-uk (65)
- # clojurescript (114)
- # clr (11)
- # community-development (105)
- # core-async (10)
- # cursive (4)
- # datascript (1)
- # datomic (58)
- # defnpodcast (3)
- # emacs (4)
- # hoplon (7)
- # juxt (3)
- # keechma (8)
- # off-topic (7)
- # om (109)
- # om-next (8)
- # onyx (26)
- # pedestal (3)
- # planck (8)
- # re-frame (76)
- # reagent (28)
- # rum (25)
- # spacemacs (2)
- # specter (35)
- # untangled (31)
- # yada (27)
@jasonjckn yes, it’s s/unform
(it’s not perfect yet, see http://dev.clojure.org/jira/browse/CLJ-2021?focusedCommentId=43842#comment-43842)
@jeroenvandijk thanks! I ran head smack right into that issue yesterday 🙂
@jeroenvandijk but used s/conformer to get around it
btw, that issue is imo a problem with conform, not unform :)
are you using conform to destructure input?
I haven’t seen too many people doing that yet but our presumption has been that it would remove a lot of fragile gross code
(let [ast (s/conform ::defui forms)
ast2 (ast-transform ast)
out (s/unform ::defui ast2)
cool, that’s great to hear about
here's my ast transformer still toying with this code
(defn ast-transform [ast]
(letfn [(walk-fn [xf]
(-> xf
(match->
{:protocol (_ :guard #(static-symbs (name %)))}
(assoc :static? 'static)
{:method-name 'render :args [this om-props] :body body}
(assoc :args [this]
:body `[(let [~(s/unform ::cs/binding-form om-props)
(om.next/props ~(s/unform ::cs/binding-form this))]
~@body)])
:else (*recur-walk*))))]
(walk-explicit-recur ast walk-fn)))
Is clojure.spec a suitable tool for validating JSON formatted HTTP request bodies? I am asking because the pervasive use of namespaced keywords specs seems to conflict with that
you can use s/keys
with :req-un
and :opt-un
for that
many people are and it’s been discussed a number of times here - you might find it in the back chat
That was what I thought about doing myself. But then I started thinking about nested maps and whether that would end up posing a problem. Probably not 🙂 You mentioned some time ago that you were thinking about adding a way to "rename" keys in s/keys. Any development on that?
nope. up to Rich whether that idea comes back, so I’m not sure if it will.
No such namespace: clojure.spec.gen, could not locate clojure/spec/gen.cljs, clojure/spec/gen.cljc, or Closure namespace “clojure.spec.gen”
Hi @liamd, according to the current clojure.spec guide, it seems you need to add [org.clojure/test.check "0.9.0"]
to your :dev
profile in your project.clj
:profiles {:dev {:dependencies [[org.clojure/test.check "0.9.0"]]}}
Or with boot
(set-env!
:dependencies '[[org.clojure/test.check "0.9.0" :scope "test"]])
Did it solve your problem ?Ho my bad, sorry. Try with [cljs.spec.impl.gen :as gen]
Maybe more information here : http://dev.clojure.org/jira/browse/CLJS-1696
that seems to have gotten rid of the import error, but i’m still not sure which things to use to get spec generation working
now it’s
clojure.test.check.generators/simple-type-printable does not exist, clojure.test.check.generators never required
Yes same for me, sometime I need cljs.spec.impl.gen
, sometime clojure.test.check.generators
. But this code
(gen/sample (s/gen int?))
effectively require clojure.test.check.generators :as gen
and cljs.spec :as s