This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # bangalore-clj (1)
- # beginners (27)
- # boot (16)
- # cider (14)
- # cljs-dev (94)
- # cljsrn (8)
- # clojure (229)
- # clojure-dev (5)
- # clojure-dusseldorf (6)
- # clojure-italy (8)
- # clojure-norway (8)
- # clojure-russia (22)
- # clojure-sanfrancisco (2)
- # clojure-spec (48)
- # clojure-uk (44)
- # clojurescript (47)
- # core-async (87)
- # cursive (43)
- # datascript (22)
- # datomic (20)
- # defnpodcast (5)
- # emacs (6)
- # hoplon (4)
- # jobs-rus (4)
- # keechma (2)
- # klipse (8)
- # leiningen (2)
- # luminus (2)
- # lumo (14)
- # om (38)
- # onyx (4)
- # overtone (3)
- # pedestal (41)
- # planck (72)
- # powderkeg (42)
- # proton (46)
- # protorepl (9)
- # reagent (9)
- # ring (47)
- # ring-swagger (5)
- # rum (7)
- # sql (22)
- # unrepl (1)
- # untangled (24)
- # vim (19)
- # yada (5)
here is an example: https://gist.github.com/eyston/c797efc5e4c07304e0c331b97decd107 — was doing the first thing and its opaque, tried the second way after reading http://thegeez.net/2016/12/09/parsing_clojure_spec_advent_of_code.html
@hueyp As someone who uses
s/conformer quite a bit, I'll caution against specs that transform their data (beyond the conforming that the specs themselves do). Alex Miller and other Cognitect folks also caution against mixing transformation into your specs. The problem is that once you put that in a spec, all client uses of the spec have no choice about the transformation -- they all have to deal with the conformer in the spec.
I’m building a parser and was kind of blown away that with conformer you could totally have it output the AST 🙂
We do it for a very specific use case: where our input is always strings (from an HTTP request) and we want numbers or keywords out of the specs (and they're coded to accept numbers or keywords too, as well as strings).
It's likely to be better for you down the road, to separate the transform to AST from the specs. Otherwise you're complecting validation (specs) with transformation. If you keep them separate, they'll be easier to test and potentially easier to reuse.
Spec is great tho'... we've been using it in production code for quite a while (we have Clojure 1.9.0 Alpha builds in production).
I’d like to write the spec with
s/keys but that only supports keywords. Am I missing something simple?
thanks! I haven’t used every-kv, but as far as I know using
map-of I can’t specify that certain keys are required and others are optional
Pretty sure the recommended approach is to conform the keys to keywords. Are you worried about performance?
but yeah, will be converting a couple thousand string keys to keywords, nested to ~20 levels deep, so would like to avoid if possible
No need for
specter, I think: https://clojure.github.io/clojure/clojure.walk-api.html#clojure.walk/stringify-keys
Benchmark to see if there’s actually a performance issue. A few thousand keys doesn’t sound like a performance bottleneck.
hiya are there any good reference projects or tutorials on how to integrate spec into real world projects
most of the examples i’m digging up explain how it works well but seem “contrived” for lack of a better term
@liamd I suspect most “real world projects” are closed source and can’t easily be discussed...
i guess i’m looking for “best practices”. do i create a new file for my specs, do i do runtime checks with them, etc.
"popular open source libs” are nearly all remaining compatible with earlier Clojure versions...
We’re unusual (at World Singles) in being willing to run Alpha versions of Clojure in production.
For libraries that need to support earlier versions of Clojure, specs must be in a separate file so that folks on Clojure 1.9 can require it, but folks on earlier versions can ignore it.
We’ve found the most value so far comes from specifying data not functions. We use spec to validate input parameters for our REST APIs and we’re starting to use it to validate user input in some web apps as well.
But it’s also part of testing — that’s where we
instrument code (prior to running our test suite, for example) and some limited automation of generative tests (beware of the increased time such testing takes — consider running it separately from your “unit tests”, so that it can be run “as needed” by developers and as long form testing in CI perhaps).
so what i’m gathering is that standard practices haven’t been established yet necessarily because it’s really still in alpha
it seems like there’s lots of space for libraries to be developed on top of spec to enforce certain uses and patterns, like perhaps ring middleware, or test suite integration or cleaner errors from
Our experience so far re “cleaner errors” is that requires application domain knowledge, so we’ve created some custom code that maps from
explain-data to our application domain, using some heuristics that work for the sorts of spec failures we might reasonably get.
As for the rest of it, yeah, I think it’s just too early for much to have solidified.
Nope, I’m in Chicago and don’t have the spare cash. Looking forward to the screen casts that come out of it though.