This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-04-23
Channels
- # announcements (2)
- # beginners (82)
- # calva (13)
- # cider (12)
- # clara (4)
- # cljdoc (22)
- # clojure (89)
- # clojure-dev (23)
- # clojure-europe (16)
- # clojure-italy (39)
- # clojure-nl (8)
- # clojure-spec (28)
- # clojure-uk (36)
- # clojurescript (40)
- # cursive (10)
- # data-science (1)
- # datomic (27)
- # devcards (4)
- # emacs (1)
- # fulcro (25)
- # jobs (1)
- # jobs-discuss (3)
- # kaocha (5)
- # luminus (1)
- # nrepl (68)
- # off-topic (64)
- # pedestal (23)
- # planck (1)
- # quil (4)
- # re-frame (6)
- # reitit (5)
- # remote-jobs (4)
- # shadow-cljs (16)
- # spacemacs (11)
- # testing (1)
I have a question about how people handle writing specs for an API endpoint. I'm speccing out ring request maps, and have several endpoints in the same namespace. a ring spec typically involves providing specs for :status
, :params
, sometimes :body
. However my spec names end up being quite wordy; for example, the expected body for a successful response of a given endpoint ends up being :my.ns.endpoint-name.response.success/body
. Over the course of defining several endpoints, with potentially multiple possible responses, I end up with quite a lot of typing. I've been considering either moving each endpoint spec into its own namespace, so that I can use ::
shorthand, but I'm not wild about the proliferation of files that will create. My other thought is to create some macro or function to help generate these specs. Any thoughts?
@robertfrederickwarner You can create a namespace alias without needing an actual namespace file.
(alias 'm (create-ns 'ws.domain.member))
and then use ::m/whatever
ah, I did not know about alias
. I had considered trying using (ns ...)
but rejected it as it seemed to be pretty unidiomatic
@alexmiller has mentioned the possibility of improving alias usage but I don't think any concrete proposal has been made yet.
It would be nice if it were possible to define a map spec assigning specs to given keys; I know that seems to be going against the grain of spec but it would cut down some lines of code needed to spec out json endpoints
e.g... we get data coming in as :some_value
whereas in our system it's :some-value
, so there's another spec to handle the conversion
spec2 has support for this for unqualified keys in s/schema
Define "ready" 🙂 We have a branch of our codebase at work that runs on Spec2.
good question - I guess, active development finished and moving into a phase of broader community use, similar to where spec.alpha is now
I would say it's likely on order of months given the set of work we have talked about
Could you give us an overview of what additional work on Spec2 is still in the pipeline?
hard to say whether that's 2 months or 6 but certainly I would love have it before the conj
we have a list of 10 areas of work for spec2
some of those we'd like to work through before "release" and re-integration, some could be add-ons later
I'd like to cut our project at work over to Spec2 but I don't know how much rework to expect (I mean, I'm used to some level of rework given how often we rely on Clojure alphas 🙂 )
you mean rework between now and "the end" ?
Between now and non-alpha status.
well, I wouldn't recommend that yet but I'm not expecting that the existing apis are going to change much
Although we're heavily reliant on Spec1 Alpha in production so I don't know why I'm all that worried...
@alexmiller don't know if you already saw it, but there are a few more ideas above on s/closed
.