This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-12-04
Channels
- # adventofcode (161)
- # asami (2)
- # babashka (56)
- # beginners (128)
- # calva (57)
- # cider (10)
- # circleci (1)
- # clj-kondo (4)
- # clojure (13)
- # clojure-europe (44)
- # clojure-france (32)
- # clojure-italy (3)
- # clojure-nl (18)
- # clojure-spec (7)
- # clojure-uk (26)
- # clojurescript (18)
- # code-reviews (15)
- # community-development (7)
- # conjure (5)
- # cryogen (8)
- # cursive (31)
- # datomic (18)
- # emacs (8)
- # events (4)
- # figwheel-main (7)
- # fulcro (42)
- # juxt (3)
- # kaocha (58)
- # lambdaisland (1)
- # malli (1)
- # minimallist (1)
- # pathom (11)
- # pedestal (9)
- # re-frame (28)
- # reagent (20)
- # reclojure (4)
- # releases (1)
- # reveal (23)
- # schema (2)
- # shadow-cljs (7)
- # test-check (67)
- # xtdb (23)
Is there a good way to have multiple generators for clojure.spec.test.alpha
& clojure.spec.gen.alpha
on the same spec on a namespaced keyword? In particular, in cases where we know that a spec is restricted in certain contexts, such as Datomic refs (which when sent TO datomic are either a 2-tuple, an int, or a map [component], while when received FROM datomic are an int or a map).
If not, my guess would be the most sensible way to do this is to just override the spec’s generator with a generator that generates the more restrictive form (e.g. int/map in the above example, or just int for non-component refs) and then do generation some other way (or not at all) for cases where you need the more general form?
Thanks!
EDIT: I think I’ve figured it out. For anyone who’s curious, this can be done by clojure.spec.test.alpha/instrument
options
Q: consider following snippet:
(s/valid? (s/keys :req [:nexus.annotation/id]) {:nexus.annotation/id 1
:nexus.annotation/annotation-set {:invalid :map}}) => false
1. Why does spec take the second (invalid) key into account? 2. Is there a way to make spec ignore the second key
Apparently this is by design:
> > In addition, the values of all namespace-qualified keys will be validated > (and possibly destructured) by any registered specs. Note: there is > no support for inline value specification, by design.
yes, it is by design