This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-10-05
Channels
- # announcements (2)
- # babashka (9)
- # bangalore-clj (4)
- # beginners (20)
- # calva (5)
- # cider (1)
- # clara (2)
- # clojure (11)
- # clojure-italy (2)
- # clojure-spec (11)
- # clojure-uk (4)
- # clojurescript (34)
- # clojutre (7)
- # code-reviews (5)
- # cursive (3)
- # datascript (7)
- # fulcro (7)
- # graalvm (8)
- # jackdaw (1)
- # malli (1)
- # nrepl (4)
- # off-topic (225)
- # reagent (23)
- # reitit (14)
- # remote-jobs (1)
- # ring-swagger (1)
- # shadow-cljs (19)
- # tools-deps (10)
@jake142 the response coercion only validates if there is a response model defined. It *should* strip away extra keys from both inputs & outputs, but looking at the code, it does it only for application/json
, so for transit & edn, the extra keys get validated - this is a feature of clojure.spec
, does it proudly, by design.
Interesting - I think I’ll need to play around with this a bit more to really get it. I do feel that transit, edn & JSON should all behave the same way, just for clarity’s sake.
All of our responses are application/json
, but when I was playing with this on Friday I could have sworn that extra keys were being validated. If I have time later this week, I may try to make a minimal test case to gain a bit of clarity.
Thanks for being so responsive, BTW. It makes it a lot easier to trust a fairly complex tool like reitit when the maintainer is accessible 🙏
> actually, for responses, I would say the default of no-op-transformer
is ok - user should ensure that responses are ok. for request, it should definetely strip.
only way not to validate those would be to strip away the extra keys from responses, currently not happening.
.. or to convince spec core team the validating extra (qualified) keys is not right.
for request, filed an issue: https://github.com/metosin/reitit/issues/317
> .. or to convince spec core team the validating extra (qualified) keys is not right. ooooh, now I understand what you’re getting at:
(s/def ::a string?)
(s/def ::b string?)
(s/def ::m (s/keys :req [::a]))
(s/explain ::m {::a "jake"
::b 20})
-- Spec failed --------------------
{:com.flexport.capital.util.auto-fk/a ...,
:com.flexport.capital.util.auto-fk/b 10}
^^
should satisfy
string?
-- Relevant specs -------
:com.flexport.capital.util.auto-fk/b:
clojure.core/string?
:com.flexport.capital.util.auto-fk/m:
(clojure.spec.alpha/keys :req [:com.flexport.capital.util.auto-fk/a])
-------------------------
Detected 1 error
I had no idea that spec did this. That’s fascinating. It makes sense - seems like a great idea. Just surprising.I think we should strip extra keys out by default for all formats. what do you think?
the code is here: https://github.com/metosin/reitit/blob/master/modules/reitit-spec/src/reitit/coercion/spec.cljc