This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-09-21
Channels
- # announcements (12)
- # architecture (26)
- # beginners (165)
- # biff (19)
- # calva (25)
- # circleci (2)
- # clj-kondo (25)
- # clojure (70)
- # clojure-dev (17)
- # clojure-europe (37)
- # clojure-nl (1)
- # clojure-norway (22)
- # clojure-spec (10)
- # clojure-sweden (1)
- # clojure-uk (24)
- # clojurescript (10)
- # clr (9)
- # cursive (17)
- # data-science (2)
- # datahike (1)
- # deps-new (1)
- # dev-tooling (3)
- # emacs (3)
- # events (7)
- # helix (10)
- # honeysql (1)
- # hugsql (3)
- # humbleui (3)
- # hyperfiddle (30)
- # introduce-yourself (3)
- # jobs (1)
- # malli (4)
- # music (1)
- # off-topic (3)
- # pathom (3)
- # polylith (6)
- # portal (7)
- # re-frame (16)
- # reitit (3)
- # releases (3)
- # remote-jobs (1)
- # shadow-cljs (23)
- # xtdb (14)
for those in the middle of the venn diagram between Polylith and Malli users; where do you write your function specs/schemas? the .<x>.interface
ns, .<x>
ns (where the func is defined), the .<x>.interface.spec
ns, or somewhere else?
Not a Malli user but a heavy Spec user -- <top-ns>.<component>.interface.specs
is my preference.
That said, for s/fdef
I generally put the specs right above the function definition. For data specs, I put them in .interface.specs
(since fn specs are generally not used separately from the function they apply to).
So that means my interface
nses will require interface.specs
if the fn spec needs data specs too.
I appreciate it @U04V70XH6! thats what I've been gravitating towards myself, nice to have confirmation
This feels like a good advice. Maybe something that we could add to the documentation?
@U0482NW9KL1 am hitting the same problem/solution space.. been delaying thinking about this for a couple weeks, but i have to convert this part of the codebase. I think the approach i'm going to take here, is a bit more declarative, 'require' is great if you have a dependency ordering, it's not needed for malli schema, in so far as there's any order to schema, it's orthogonal to require load order , the most efficient registry choice is actually just a java.util.HashMap that's precomputed at load time which maps keys to schema. So basically, at load time, i'm just going to search for 'spec.clj/schema.clj' or 'spec.edn/schema.edn' on the classpath, load them all, merge all the maps (key->schema), throw if there's any key conflicts, then finally convert it to a java.util.HashMap, and then you have your malli registry. Also you can do all this at 'compile time', so AOT builds will have full merged registry precomputed. Probably going to start implementing this soon, i can send you code snippets if you're interested in this approach. Other suggestions here in this thread are great too.