What Clojure Spec is and what you can do with it

263 点作者 icey超过 4 年前

13 条评论

gw超过 4 年前

I think the instrumenting and generator stuff gets disproportionate attention. For me by far the biggest win from spec has been with parsing. This completely changes how you'd write a library that takes a data structure and parses it into something meaningful (for example, what hiccup does for html or what honeysql does for sql).In the past, this required a lot of very ugly parsing code and manual error-checking. With spec, you write specs and call s/conform. If it failed, you get a nice error, especially if you pair it with expound. If it succeeded, you get a destructured value that is really easy to pull data out of. I've done this in a half dozen different libraries and i'm pretty sure i wouldn't have even written them without spec.

评论 #24433500 未加载

评论 #24435247 未加载

评论 #24435219 未加载

评论 #24433419 未加载

评论 #24434983 未加载

评论 #24433785 未加载

tekacs超过 4 年前

As a very heavy user of spec, I’ve since switched to using Malli [0], which is similar but uses plain data to model specs (and doesn’t use Clojure Spec at all).Also, Malli is being funded / supported by Clojurists Together [1], which is a wonderful initiative that’s also worth a look.[0]: <a href="https://github.com/metosin/malli" rel="nofollow">https://github.com/metosin/malli</a>[1]: <a href="https://www.clojuriststogether.org/news/q3-2020-funding-announcement/" rel="nofollow">https://www.clojuriststogether.org/news/q3-2020-funding-anno...</a>

jwr超过 4 年前

I found spec very useful and use it more and more. I'm looking forward to newer revisions, with support for optionality, it's been a big problem area in my case.Here's a quick list of gotchas (well, they got me, so perhaps other people will find this list useful):* `s/valid?` does not actually tell you that the data is validThe naming of `s/valid?` suggests that you can call it on your data and find out if the data is valid according to the spec. This isn't true. What it actually tells you is if the data, when conformed, will be valid according to the spec. If you pass the data as-is to your functions (without passing it through `s/conform`), you might find that they will be surprised at what they get.* Conformers are likely not what you think. They are not intended for coercion and have many pitfalls (for example, multi-specs dispatch on unconformed value).* s/merge doesn't necessarily do what you wanted if you're using conformers, only the last spec passed to merge will be used for s/conform (but you're not using conformers, right?)* specs are checked eagerly. If you think that (s/valid? ::my-spec x) will only check ::my-spec, that is not the case. It will check any key of x found in the spec registry.I settled on a subset of spec, because of the pitfalls.

评论 #24434913 未加载

评论 #24433148 未加载

评论 #24437330 未加载

hospadar超过 4 年前

We use spec A LOT to validate a huge config file/DSL thing for our internal ETL application.My general feelings are:- spec is great, you should use it, the composeability and flexibility are awesome features.- I've never once used conformers - maybe I just don't "get it" (which if so, speaks badly of them I think since I've been heavily using spec for years), but the use cases for them seem strange to me and I feel they cause more confusion than they're worth. I wish they were separated out into more separate/optional functionality.- It's SO MUCH more powerful than things like JSON schema, but that comes at the cost of portability - there's no way we could send our spec over the wire and have someone else in a different environment use it. But also, there's no way we could implement some of our features in a tool like JSON Schema [and have it be portable] ("Is the graph represented by this data-structure free of cycles?" "When parsed by the spark SQL query parser, is this string a syntactically valid SQL query?").- Being able to spec the whole data input up front has saved hundreds of lines of error-checking code and allows us to give much better errors up-front to our users and devs- Spec has a lot of really cool features for generative testing, but we rarely use them since we've implemented lots of complex specs where it's not really practical to implement a generator (i.e. "strings which are valid sql queries" or "maps of maps of maps which when loaded in a particular way meet all the other requirements and are also valid DAGs"). I feel torn about this because the test features are great, but the extreme extensibility of spec is what I love most about it. I haven't often found a scenario where I actually have a use for the generative features (either the data is so simple I don't need them, or so complex that they don't work).

评论 #24433434 未加载

评论 #24435157 未加载

评论 #24433171 未加载

评论 #24433172 未加载

Jeaye超过 4 年前

I strongly recommend that anyone using spec for validation should check out Orchestra, to instrument the functions and have them automatically validated on each and every call: <a href="https://github.com/jeaye/orchestra" rel="nofollow">https://github.com/jeaye/orchestra</a>For my team, generators and parsing are basically useless with spec. We just don't use them. But describing the shape of data and instrumenting our functions, using defn-spec, to ensure that the data is correct as it flows through the system is exactly what we want and nothing I've seen in Clojure land does it like spec + Orchestra can.I think part of this may boil down to different types of testing. We primarily use functional testing, especially for our back-end, so we're starting from HTTP and hitting each endpoint as the client would. Then we ensure that the response is correct and any effects we wanted to happen did happen. This is much closer to running production code, but we do it with full instrumentation. Being able to see an error describing exactly how the data is malformed, which function was called, and what the callstack was is such a relief in Clojure.<pre><code> Call to #'com.okletsplay.back-end.challenge.lol.util/provider-url did not conform to spec. -- Spec failed -------------------- Function arguments (nil) ^^^ should satisfy (-> com.okletsplay.common.transit.game.lol/region->info keys set) -- Relevant specs ------- :com.okletsplay.common.transit.game.lol/region: (clojure.core/-> com.okletsplay.common.transit.game.lol/region->info clojure.core/keys clojure.core/set) ------------------------- Detected 1 error</code></pre>

评论 #24435074 未加载

reitzensteinm超过 4 年前

My pet project is a partial evaluator for Clojure code that uses data generated from spec to fuzz code and optimize it. The coverage is accepted as complete, so there are no guards and deoptimizations like you'd have in a JIT, the programs are just wrong.It seems like a fairly powerful technique, although you couldn't ever rely on it with production code. After several years of tinkering I managed to get a Forth interpreter written in Clojure executing a specific input string partially evaluating down to OpenGL shader code, to hardware accelerate my friend's Stackie experiment (link to his version below).(nth (sort [0 n 5]) 1) where sort is a merge sort also successfully compiles down to just the branches you'd hand optimize it to, which is Graal's party trick. Although they're solving the problem in a bulletproof general way, so the difficulty is incomparable.The eventual goal is to write Clojure in Clojure without it being horrendously inefficient.<a href="http://blag.fingswotidun.com/2015_09_16_archive.html" rel="nofollow">http://blag.fingswotidun.com/2015_09_16_archive.html</a>

dustingetz超过 4 年前

At Hyperfiddle we are using spec to specify UIs, so e.g. (s/fdef foo :args (s/cat :search-needle string? :selection keyword?) :ret (s/coll-of (s/keys ...))) describes exactly what you need to render a masterlist table with some query parameters. It's being used with pilot customers, now in production. This stuff works!

krn超过 4 年前

Malli[1] and specmonstah[2] are my favourite Clojure(Script) libraries built on top of Clojure Spec.[1] <a href="https://github.com/metosin/malli" rel="nofollow">https://github.com/metosin/malli</a>[2] <a href="https://github.com/reifyhealth/specmonstah" rel="nofollow">https://github.com/reifyhealth/specmonstah</a>

评论 #24433626 未加载

john-shaffer超过 4 年前

If you're considering using spec, you should know that spec alpha2 is significantly different internally, and is much easier to write tooling for, but has not been ported to ClojureScript. I would highly recommend trying alpha2 if you're not using CLJS, even if it's a little less stable.<a href="https://github.com/clojure/spec-alpha2" rel="nofollow">https://github.com/clojure/spec-alpha2</a>

kmclean超过 4 年前

I find spec really interesting but struggle to find a good fit for it in my projects. I end up getting bogged down writing generators and give up, or end up breaking down functions into such small pieces that speccing every one of them results in an unreasonable proliferation of specs and generators. This was an interesting and helpful overview of some different ideas about how to take advantage of spec, so thank you!Also I definitely share your feelings about clojure massively increasing my job satisfaction and teaching me how to think about programming in a new (and better tbh) way.

评论 #24433182 未加载

amgreg超过 4 年前

> Still alpha: spec is still alpha and it looks like it will remain like that since the intention is for spec2 to completely replace it in the future.Out of curiosity for the folks in the know: why is this the state of affairs? Where we have the library in alpha for a long time, and being replaced already?