This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-28
Channels
- # beginners (79)
- # boot (24)
- # cider (5)
- # clara (5)
- # cljs-experience (5)
- # clojure (126)
- # clojure-greece (5)
- # clojure-italy (3)
- # clojure-losangeles (1)
- # clojure-russia (1)
- # clojure-spec (21)
- # clojure-uk (31)
- # clojurescript (151)
- # community-development (20)
- # cursive (25)
- # datomic (24)
- # flambo (1)
- # fulcro (312)
- # graphql (10)
- # hoplon (20)
- # juxt (2)
- # keechma (6)
- # leiningen (7)
- # luminus (4)
- # om (4)
- # onyx (7)
- # parinfer (24)
- # protorepl (1)
- # re-frame (7)
- # reagent (13)
- # shadow-cljs (19)
- # spacemacs (14)
- # specter (14)
- # uncomplicate (22)
- # unrepl (1)
Is there a way to spec a nested map that dispatches on type? e.g.
(s/def :app/command (s/keys :req [:command/id
:command/params
:request/id
:idempotency/id]))
(defmulti command-params :command/id)
(s/def :command/params (s/multi-spec command-params :command/id))
(defmethod command-params :test/command [_]
(s/keys :req [:material/id]))
;; This is the kind of map shape I want
{:command/id :test/command
:request/id (random-uuid)
:idempotency/id (random-uuid)
:command/params {:test/id (random-uuid)}}
I thought I could do this with a multi-spec, but I'm not sure how to define a multi-spec where the data is at one level, and the tag is at the parent level
Idea: s/conform
could be changed into s/walk
that could be parametrised to do either :conform
(as now) or :coerce
(like conform, but would not return the branch-information, e.g. same results as with conform + unform).
Is there any sort of consensus on where to put specs? Separate ns? Same ns as things being specced?
It Depends(tm).
Data specs can usually be in their own ns, possibly with a few predicate functions or closely related helper functions.
Function specs probably should be in the same ns as the functions they are spec'ing -- unless you need to support Clojure 1.8 (or earlier) as well as Clojure 1.9, such as for a library, in which case they must go in a separate, optional ns, that only 1.9 users will load.
Tooling makes me feel like the same ns might be more convenient - not necessarily better?
for instance cider’s doc command doesn’t work unless you explicitly have the spec required
Remember that s/def
will only update the spec -- not all the other specs that have been defined in terms of that spec.
yeah, this should work (once you re-def the other specs)