This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-05-25
Channels
- # aws (2)
- # beginners (57)
- # boot (31)
- # carry (15)
- # cider (9)
- # cljs-dev (9)
- # cljs-experience (32)
- # cljsrn (94)
- # clojure (129)
- # clojure-dusseldorf (3)
- # clojure-greece (4)
- # clojure-italy (8)
- # clojure-norway (3)
- # clojure-russia (344)
- # clojure-sg (39)
- # clojure-spec (2)
- # clojure-uk (39)
- # clojurescript (84)
- # core-async (99)
- # cursive (10)
- # data-science (1)
- # datascript (4)
- # datomic (66)
- # emacs (10)
- # graphql (4)
- # hoplon (28)
- # jobs (15)
- # luminus (3)
- # lumo (5)
- # off-topic (23)
- # om (4)
- # onyx (32)
- # pedestal (24)
- # re-frame (2)
- # reagent (7)
- # ring-swagger (32)
- # spacemacs (4)
- # untangled (57)
- # utah-clojurians (1)
Ideas about the new validation errors, comments welcome: https://github.com/metosin/compojure-api/issues/304
Hey, I am trying to do something a little unorthodox and I was wondering what is responsible for turning the :params
key in a request into the lovely :query-params
key in the request?
I thought it might be compojure.api.middleware/api-middleware
but I couldn’t figure out how it gets the swagger information
Context: I am converting our API to use the compojure.api resource
style stuff. However we also have websocket subscriptions that work the same way. So I have the :handler
function as a defn
and I would like to use that same function to handle the WS request too. However that handler is expecting the parameters in :query-params
but the WS is passing the params as :params
to mimic Ring.
@kasuko it’s it other way around, api-middleware
installs ring.middleware.params/wrap-params
which reads :query-params
(and others) into :params
. You could write a custom middleware to do this the other way around. With the latest alpha, you can also add middleware directly to resources.
the swagger information is collected by the api
function (https://github.com/metosin/compojure-api/blob/master/src/compojure/api/api.clj#L18-L73): it reads the paths and transforms their information into swagger definitions, and merges the top-level swagger data to it. Data is injected into the request (together with the reverse-routing information to enable bi-directional routing) and by so, is available to all routes under the api. the swagger-docs
handler just reads it from the request.
all Route
s self-contain all the ring-swagger-data, you can print any Route
(`api`, context
, GET
, resource
, …) in the repl to see how their data, including the swagger-stuff.
and calling compojure.api.routes/get-routes
on a Route
gives the cumulative routing tree, with all the extra data.
@ikitommi , im taking a look into your example of a spec
error
what does the :spec "(clojure.spec.alpha/keys :req-un [::a])
stands for? this is the error msg that will be sent to the client if it fails to meet the spec?
@plins that would be the s/form
of the spec. The ::a
shouldbe :user/a
as its expanded there
it would be really nice to set a custom msg if some validation fails, sometimes the errors get quite confusing (specially to a third party client consuming the api with no knowledge of clojure at all)
changing subject here, is there a canonical way of setting a default value for a field? im struggling with limit and offset values
ive read some discussions on github regarding this topic but wasnt able to figure out how to do it
real default, in eg. if the user do not provid an offset and limit i could just accept the request (instead of 400) and use some default value
letk-syntax has that, but if you define schemas as data/maps (e.g. :body
or with resources
), there isn't a mechanism for that in Schema core.
but to get the defaults in, you need to run explicitely confom
or coerce
with a conformer/coercer that applies the defaults. And the original spec/schema needs to have a :default
data Needs some plumbing to get working now.
@kasuko, maybe do (update request :query-params merge (:params request))
before the handler in the ws?