This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-08-15
Channels
- # announcements (1)
- # beginners (101)
- # boot (13)
- # cider (38)
- # cljdoc (10)
- # cljs-dev (37)
- # cljsrn (6)
- # clojure (74)
- # clojure-dev (8)
- # clojure-europe (3)
- # clojure-italy (36)
- # clojure-losangeles (2)
- # clojure-nl (5)
- # clojure-spec (15)
- # clojure-uk (49)
- # clojuredesign-podcast (2)
- # clojurescript (52)
- # cursive (6)
- # datomic (19)
- # fulcro (35)
- # graalvm (16)
- # graphql (4)
- # kaocha (1)
- # leiningen (26)
- # luminus (3)
- # re-frame (10)
- # reagent (14)
- # ring-swagger (37)
- # rum (2)
- # schema (4)
- # shadow-cljs (148)
- # spacemacs (13)
- # specter (1)
- # sql (46)
- # tools-deps (3)
- # vim (4)
Hello! Is there a way to prevent conversion from clojure.spec to spec-tools.core/Spec
objects using compojure.api
? PS: I don’t need a swagger schema at all.
@bohdan.mikhail mostly you don't need to wrap anything into Spec
s. Sometimes you do, can't recall all the cases, here are the docs https://cljdoc.org/d/metosin/spec-tools/0.10.0/doc/spec-driven-transformations
I don’t do that. I just need to reverse parse explain-data
output but after spec-tools
I’ll get spec-tools.core/Spec
object instead of a keyword in :spec
field.
that’s unfortunate. It could nowadays work without the automatic wrapping as spec-tools changed from conforming-based coercion to form-based. But don’t have extra time to try that one out. The wrapping is in the spec-coercion namespace. You could try to remove that and see if everything works.
if people need coercion with spec, please poke the Cognitect core devs. Currently out-of-scope, and spec-tools has to do dirty tricks to make it work.
Any reason Metosin implements its own validation library instead of adopting JSON Schema? You might have had this question a 100x by now, just curious.
@borkdude there is rationale in README (https://github.com/metosin/malli/blob/master/README.md#motivation). Is is modelled from JSON Schema, which is imo, good for tooling but has really bad developer ux. Also, bit of NIH ;)
Have started with JSON Schema in few projects, but ended up cooking a ad-hoc clojure data definition language for form generation.
Currently 370 lines, does validation, full programming errors (e.g. spec explain-data) and coercion.
seems like jinx was started bit earlier than malli. Spec doesn't seem to deliver all the things we need as the libs keep popping up..
so you can have a custom predicate registry but if you serialize it to some other party, you have to ensure that party also has that same function registered, right?
it reminds me a bit of something I made: https://github.com/borkdude/sci this enables you to evaluate a string of Clojure code safely in CLJS and CLJ, so you can just create any function you want from safe ingredients
this way you could ensure that the other party registers a custom function under the same key as you did
@borkdude yes, all parties need to have the same registry if there is custom predicates (like EDN & Transit has readers & writers) - unless the code is passed around too. Would be nice to do a poc sci for that. Have you thought about things like security and the halting problem?
Currently are already some helpers to compose higher level schemas from data, like [:and {:id :domain/age, :name "Age, must be over 18"} int? [:> 18]]
.
@ikitommi security: you shouldn't trust the code, but you can trust the evaluator, since you decide what goes in. halting problem: yeah, you can do (reduce (fn [_ x] x) (range))
I guess, I have no answer to that except for maybe executing in in a future with a timeout?
currently sci only has "pure" functions from clojure by default, but you can register additional "dangerous" functions and values at your own risk
maybe an option to only register some functions like predicates and other combinators that are guaranteed to terminate will work
that would be super! wrote https://github.com/metosin/malli/issues/35#issuecomment-521737930