This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-07-17
Channels
- # announcements (11)
- # beginners (29)
- # calva (2)
- # clara (12)
- # cljsjs (1)
- # cljsrn (7)
- # clojure (39)
- # clojure-europe (6)
- # clojure-nl (7)
- # clojure-spec (6)
- # clojure-sweden (1)
- # clojure-uk (15)
- # clojuredesign-podcast (6)
- # code-reviews (2)
- # conjure (29)
- # cursive (3)
- # datomic (13)
- # duct (15)
- # emacs (1)
- # figwheel-main (2)
- # fulcro (7)
- # graalvm (16)
- # lambdaisland (4)
- # luminus (1)
- # meander (15)
- # observability (15)
- # off-topic (27)
- # parinfer (7)
- # pathom (2)
- # reitit (2)
- # rum (11)
- # shadow-cljs (57)
- # spacemacs (6)
- # sql (56)
- # tools-deps (36)
- # xtdb (3)
hello, we’ve recently started using specs and have a few questions regarding how to load them correctly
say we have a namespace identity-provider
and wish to have specs for identity-providers in a s_eparate file_, how would we go about doing that? We’re looking at putting the actual specs into a separate namespace as otherwise we’re having cycling import issues
if we put our specs in a separate file/namespace (say specs.core
, and named them as :core.identity-provider/id
, :core/identity-provider
would we need to then require :refer :all
in consumer namespaces to ensure they’re loaded?
Would it be more sensible to have a separate file for each entity specs, e.g. specs.identity-providers
? How would the ‘root’ object for the identity-provider
look in that case (rather than using the name :core/identity-provider
)
You don't need to refer
specs. Just requiring the namespace they're in will cause them all to be registered.
It's common to put data-describing specs in a separate namespace from code. As long as you require that spec namespace somewhere (anywhere, early in your execution path), those specs will then become globally available.
thanks for your response, so would it be common practise to load all specs in the server entrypoint, or a user.clj
dev-namespaced file for use in the repl, rather than loading them in the code which is using them?
I don't know if this is at all good practice, but we have a ns per 'entity' for our specs to keep things readable, specs in one namespace can refer to others outside of their namespace by using fully qualified keywords (as normal), and then we have one ns which just requires them all. Those are all package together as one dependency, then anything that wants to use them just imports the dependency and requires that one namespace.