Fork me on GitHub
Misha Bohdan11:08:46

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 Specs. Sometimes you do, can't recall all the cases, here are the docs

Misha Bohdan13:08:38

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.


direct support from spec would make things so much better


(and faster)


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.


(I just saw the juxt blog post)


@borkdude there is rationale in README ( 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.


now just wrapping all ideas as a lib. Also, will be really, really, fast


Currently 370 lines, does validation, full programming errors (e.g. spec explain-data) and coercion.


And it's all data :)


nice. did you know juxt was developing jinx at the same time?


it seems now we have two new libs to choose from in this space 🙂


no, found it few days ago.


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..


yeah, being able to serialize these things is a nice property of "just data"


Need to test jinx, good to have options.


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: 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


and you can send that string back and forth


this way you could ensure that the other party registers a custom function under the same key as you did


but I guess you can go a long way with just plain data structures


@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

👌 4

that would be super easy to implement (only explicitly allowing certain functions). I'd say just try it out if it's useful at all and then I'd be happy to implement it after you let me know in an issue


will try, thanks @borkdude