This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-23
Channels
- # bangalore-clj (5)
- # beginners (136)
- # boot (1)
- # bristol-clojurians (6)
- # cider (46)
- # cljs-dev (172)
- # cljsrn (35)
- # clojure (82)
- # clojure-china (2)
- # clojure-dev (9)
- # clojure-dusseldorf (1)
- # clojure-finland (15)
- # clojure-italy (54)
- # clojure-norway (4)
- # clojure-russia (6)
- # clojure-spec (19)
- # clojure-uk (61)
- # clojurebridge (1)
- # clojurescript (55)
- # community-development (23)
- # cursive (7)
- # datomic (19)
- # emacs (10)
- # events (4)
- # fulcro (108)
- # graphql (7)
- # hoplon (1)
- # leiningen (7)
- # lumo (14)
- # off-topic (68)
- # onyx (23)
- # parinfer (8)
- # portkey (40)
- # precept (11)
- # re-frame (5)
- # reagent (40)
- # ring-swagger (5)
- # shadow-cljs (58)
- # specter (5)
- # tools-deps (37)
- # unrepl (13)
- # vim (9)
- # yada (12)
@jmckitrick closures in the top-level like this:
(defn app [{:keys [db] :as system}]
(api
(GET "/users" [] (ok (user/get-users db))
(more-routes system)))
old way was to add :components
into api-options and use the :components
to extract that at runtime. I think we could remove that for 2.0.0 as a not-good-idea.
What was the problem with that approach? @ikitommi
@ikitommi wanting to pick your brains; I keep thinking that in #compojure-api 2.+, defaults for :compojure.api.exception/request-validation
should be 400 not 500, since if one specifies a spec/schema for e.g: :query-params
and they fail to validate, i think that's a client error? thinking that default of 500 for :compojure.api.exception/response-validation
makes sense, since the server is always responsible for the response... except that if you want to attach the failing spec for validation-error to the response.... :thinking_face:
What do you all know about ‘pact’ testing?