This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-21
Channels
- # beginners (65)
- # boot (24)
- # cider (2)
- # clara (13)
- # cljs-dev (45)
- # clojure (48)
- # clojure-dusseldorf (2)
- # clojure-italy (69)
- # clojure-norway (1)
- # clojure-russia (5)
- # clojure-sanfrancisco (1)
- # clojure-spec (51)
- # clojure-uk (34)
- # clojurescript (312)
- # cursive (5)
- # datavis (1)
- # datomic (9)
- # duct (13)
- # editors (3)
- # emacs (2)
- # fulcro (11)
- # graphql (19)
- # hoplon (1)
- # immutant (2)
- # jobs (7)
- # jobs-discuss (38)
- # lein-figwheel (1)
- # luminus (6)
- # off-topic (2)
- # parinfer (10)
- # pedestal (1)
- # re-frame (9)
- # reagent (28)
- # reitit (1)
- # remote-jobs (12)
- # ring-swagger (26)
- # shadow-cljs (232)
- # slack-help (8)
- # tools-deps (29)
- # unrepl (29)
- # vim (10)
- # yada (31)
Another question. In swagger-ui, there’s a column for ‘description’ for each of the parameters. How can I get a value into that column for each parameter?
@jmckitrick good questions! second one: https://github.com/metosin/compojure-api/blob/e1d7eadbc7ecd56385191801e8572f9f9142fb8a/examples/thingie/src/examples/thingie.clj#L58
I saw that, but does it work with spec, @ikitommi?
no. spec uses spec-tools, which has the new syntax. I believe it reads the :json-schema/description
field.
(st/spec
{:spec integer?
:name "integer"
:description "it's an int"
:json-schema/default 42})
Ah, ok.
e.g.
(schema-tools.core/schema
{:schema s/Int
:description "it's an int"})
(spec-tools.core/schema
{:spec int?
:description "it's an int"})
Perfect. I’ll try it out shortly
we are porting all the stuff from ring-swagger int schema-tools (and polish things), will also work with ClojureScript, which is kinda awesome 🙂
Very cool!
I want to help with the docs as well.
that’s really good. the auth docs… many people have been asking about ready integration into auth via buddy. We have had many versions of those, but nothing that could have been pushed to c-api.
Thanks to Colin, Cursive does static analysis on all the c-api macros, could be those too. But super busy with a project and with all the libs, don’t have extra time to do those. Feel free to suggest something 🙂
My first question is what needs to be documented for c-api that isn’t covered by the existing buddy docs?
It makes sense to just add links to the example projects with buddy to start.
some people have used custom keys meta-data like :roles
to mark who can access the routes. and :user
to bind the buddy user. Not sure is that a good idea to have those in c-api itself.
still kinda stuck on this - I am using compojure.api.sweet when I access it from ClojureScript I get No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ’http://localhost:8080' is therefore not allowed access. Where do I fix that in the compojure-api.sweet setup?
@fingertoe If you want to access make http requests from one origin to another, you need to enable CORS headers, you can use: https://github.com/r0man/ring-cors
Like from localhost to http://example.com, or probably from localhost:3000 to localhost:8080, in latter case it is probably better choice to also serve the Cljs app from same origin as the API so there is no need for CORS
@ikitommi So if user and roles shouldn’t be in c-api, where would be a better place?