This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-17
Channels
- # beginners (45)
- # boot (33)
- # chestnut (9)
- # cider (2)
- # cljs-dev (24)
- # cljsrn (1)
- # clojure (114)
- # clojure-conj (3)
- # clojure-dev (3)
- # clojure-dusseldorf (3)
- # clojure-greece (5)
- # clojure-italy (22)
- # clojure-russia (10)
- # clojure-spec (12)
- # clojure-uk (19)
- # clojurescript (117)
- # core-async (16)
- # cursive (3)
- # data-science (1)
- # datomic (5)
- # docs (13)
- # emacs (1)
- # fulcro (13)
- # graphql (1)
- # hoplon (20)
- # immutant (3)
- # jobs (1)
- # juxt (12)
- # lein-figwheel (1)
- # luminus (4)
- # off-topic (12)
- # onyx (61)
- # portkey (1)
- # re-frame (21)
- # reagent (26)
- # ring-swagger (38)
- # rum (1)
- # shadow-cljs (222)
- # slack-help (4)
- # spacemacs (11)
- # specter (67)
- # uncomplicate (236)
@ikitommi some sort of (st/add-custom-coersion [:body :formats "application/json" :timestamp] json-timestamp->long)
(st/spec
{:pred (partial DateTime)
:coercion {:string str->date-time}
:json-schema/examples "..."})
and how would you then control which part of the lifecycle you’d want coercion in (request/response)?
There are three scopes for coercion (`:request`, :response
and :string
), but only two modes (`:json` and :string
).
As a newcomer to this project, I guess the fact that :string is present both in scope and mode kind of confuses me. But that might just be me.
the Spec Records should not know anything about the request/response, but they should know what kind of coercion should occur. Schema had string
and json
.
thanks, want to make things easy too. There was an idea with schemas, how to bundle ceorcion + encoding + decoding into a one concept: adding a type could be done in one place. I think we could do that now, for both Schemas & Specs. Idea is described here: https://github.com/metosin/web-schemas
As jsonista supports explicit mappings (opposed to Cheshire having global extensions), we can do this now.
e.g. introduce MyNewType
, one can describe all the things (encode, decode (multiple formats: json, edn, transit), coercion in different types, docs) in single definition. With syntax validation. Muuntaja, Jsonista and Schema/Spec-tools would take parts of those and together they would just work. And there would be a test-suite: “which types can I pass in which contexts?”
Currently, if a EDN-writer is missing for a custom type, it can fail at runtime when first time tried to pass over the wire. Temporal runtime coupling. Which is BAD.