Hi, Trying to grasp coercing with spec. Playing with this ex https://github.com/metosin/reitit/tree/master/examples/http-swagger Why does request params get coerced based on spec, but response do not. {200 {:body {:total pos-int?}}} If my response is :total "123" it won't coerce "123" to 123 and throw and error.

@johan178 I think the response is more for validation than coercion

@toni.vanhala thanks. I read it before, but I still could not understand why it was solving problem differently than specs :)

Now I do :)

Wow how did you make it so fast?!

@johan178 you can override the muuntaja settings. there should be examples to override the muuntaja transit format readers/writers in both muuntaja docs and hopefully in the reitit docs.

main focus for reitit 1.0.0 is to get coherent configs (and config errors) for everything. now, it’s… bad.

@neo2551 performance is built from bottom-up, by separating compilation & execution. With coercion, the uber case is a deeply nested map+vector schema, where all subschemas can be presented in JSON. The transformation compiler with json-tranformer puns nil out of the pipeline and the top level m/transformer returns identity = “nothing to do”. Can’t beat that 😉

Haha nice one

@rschmukler great explanation. will check the issue comments later today

hi! love the swagger integration so far but i'm not really experienced with spec… how do i specify optional query parameters?

and ideally i don't want fully qualified keywords

I hoped I could just do a (s/nilable string?) but it was still coerced into a required parameter

are you using clojure.spec or data-specs?

I just started sketching out the API, so that's not set in stone

How are the docs for data-specs? Would it provide a lot of cognitive overhead?

https://cljdoc.org/d/metosin/spec-tools/0.10.0/doc/data-specs

for normal specs, use :opt for keys, with data-specs, you wrap the keys with ds/opt.

could be a sample of both in the coercion docs...

Thanks!

Hi, is it possible to prevent route conflicts by constrain valid chars in path parameters?

@akiel welcome! there are no route guards in reitit, by design. I think such a thing could be built already, but making it performant would be non-trivial.

it would basically be linear matching on guarded routes and allowing some kind of guard function to ignore a match (and finding next match).

one thing I was thinking was to add a route data hint :conflicting etc, which would allow one to mark conflicting routes manually. This way, if there is just few routes conflicting, marking them would allow the conflict resolution to be enabled for other routes.

Understand. I have routes like Patient/{id} and Patient/_history, were Id’s can’t contain underscores. So in this special case I could think about a performant implementation. But in a general guard case you are right.

you can order the routes like so that Patient/_history is first, Patient/{id} is second. If you disable the conflict resolution, they (only the conflicting ones) will be run in order so the first one matches.

@tonsky had a nice sorted which reordered the routes automatically so that the wildcards are last, in some gist..

actually, it was on pedestal, but ported that to reitit, here’s the gist: https://gist.github.com/ikitommi/d3382348ac50639ae7914ffc0f19bb0f. Original: https://tonsky.me/blog/pedestal/