no

I just started to write my specs like that. Not sure if is the best practice or not.

I usually do

The second answer here gives a good arguments

https://stackoverflow.com/questions/37942495/where-to-put-specs-for-clojure-spec

I lean towards: data specs in a separate file(s), function specs – next to actual implementation. (Yet to see how it'll turn out in longer run)

@U051HUZLD Right, that makes sense to. Because functions might share data specs, right?

@U489U338R yes, and, functions are more "implementation detail"-y than data, I think. But I'd start with everything in one file, and see what's up later in project.

Most of our specs are for data structures and they go in whatever is the appropriate namespace for those data structures -- which is often a separate ns but sometimes is a ns with some "utility" functions specific to the data structure. Where we spec functions we generally put the spec right above the function (like a type annotation).

But, as noted, if you want your code -- a library -- to be usable by Clojure < 1.9 then you have to put specs in a separate and completely optional namespace.

See, for example, how clojure.java.jdbc handles this (specs in a separate namespace on their own -- even for functions).

sure, but I wanted to be able to be strict conditionally

oh sorry, I didn't look closely

I'm not sure I follow your logic. It seems to me your overcomplicating it.

If conceptually the id of entity is supposed to be the same as the id of todo, the you s/def :some-ns/id. And in your spec for entity you say keys req [:some-ns/id]. And do tje same in your todo spec.

Basically s/keys describes an associative structure which when used with :req says that the structure must have as keys the given list of namespaced keywords. If the keyword has a spec defined, it will be used to validate and conform the value of the key.

The todo example does use the :some-ns/id approach

But if I were to define (s/def ::entity/id ...) how can I then import that elsewhere?

This might just be a misunderstanding of clojure O_o

(:require [todos.entity.spec :refer [?])

or even if you use :as - since its already namespaced in the spec - is there a way to get at it?

thank you for the reply by the way 🙂

You don't need to refer anything, just require it. (:require [todos.entity.spec]) Specs are always defined globally. All that needs to happen is your app must eval the s/def form before you use it. Require will do that.

Also, ::entity/id doesn't make sense. It would be :entity/id

So specs are namespaced. They're globally accessible from anywhere after they've been deffed, but they need to be prefixed with a namespace. This helps reduce name clash.

So if you are in namespace todos.entity.spec and you s/def a spec, and you use the double colon ::, then you created :todos.entity.spec/your-spec

Now if you are in say todos.app namespace, you can require todos.entity.spec and refer to the spec as :todos.entity.spec/your-spec

If what you want it :entity/id instead of :your-ns/is you have two options

Either define the spec like that, so don't use the double colon, you can (s/def :entity/id int?) for example

This will be make it less portable though, since the chance of name clash are higher.

Or you can define it prefixed with the full namespace using ::, and then when you use it elsewhere, you can alias the namespace as entity.

`(ns ns1) (s/def ::id int?)` Then in ns2 `(ns ns2 (:require [ns1 :as entity]) (s/def ::user :entity/id)`

As far as I know, you can't refer a spec yet. But you can kinda manually do it if you want

(s/def ::id :some-other-ns/id)

Can you serialize to edn instead? That generally works better for Clojure.

cheshire do it without extra settings

@U2J4FRT2T it looks like it cannot encode functions (`:pred` key in the spec problems)

@U0K064KQV I am consuming it from a JS frontend so EDN does not seem ideal

depends on what you plan to do with predicates.

@U051HUZLD not much, I just want a string so I can know why validation failed for a specific field

then (map #(update % :../pred pr-str)) or something, prior to json-serialization

Or just use s/explain-str instead of s/explain-data

Or would that be too opaque? 🙂

I always wished cheshire offered custom encoders.

@U06GVE6NR too opaque; I need to know which fields contain errors 🙂

@U051HUZLD I didn’t know the function pr-str; thank you!