Fork me on GitHub
#reitit
<
2020-08-13
>
Casey08:08:28

I'm trying to figure out how to troubleshoot failing coercions, I can't seem to get a handle on the actual error.. attached here is my ring handler and retitit route. I'd like to apply expound to the spec error (https://cljdoc.org/d/metosin/reitit/0.5.5/doc/ring/pluggable-coercion#pretty-printing-spec-errors), but I can't even get a handle on the spec error heh. Anyone have tips?

ikitommi08:08:01

@ramblurr the coercion with ring is done using middleware, not using a :compile hook.

Casey08:08:56

thanks @ikitommi that really helped. :reitit.middleware/transform dev/print-request-diffs is amazing!

Casey08:08:41

and now adding the custom exception middleware to use expound as described in the docs, works 😁

Casey09:08:00

My reitit ring handler is wrapped in the https://github.com/ring-clojure/ring-defaults middleware (wrap-defaults (reitit.ring/ring-handler (reitit.ring/router ....))) I'd like to invert it so that the defaults middlewares are all inside, defined in the :middleware key of the reitit handler definiton.

Casey09:08:46

(mainly so that I can apply the request diff transform to all the middleware)

ikitommi09:08:27

you can look at the source code of the wrap-defaults and put the relevant mw into router :data :middleware vector, e.g.

(ring/router
  {:data {:middleware [[wrap-anti-forgery (get-in config [:security :anti-forgery] false)]
                       [wrap-flash (get-in config [:session :flash] false)]]}})

Casey09:08:46

The naming confuses me. Is it convention that a function prefixed with wrap- is the higher order function that accepts the handler and returns a function (fn [request]) (the actual middleware?)

Casey09:08:10

When one talks of middleware are they referring to this handler wrapping function or the inner function?

ikitommi09:08:52

the vector syntax is meant for the wrap- style middleware. the handler is injected as first argument, e.g. [wrap-something {:option "kikka"}] is turned into (wrap-something handler {:options "kikka"})at router creation time.

👍 3
ikitommi09:08:35

I think that the “thread-first optimized” convention is really bad in Ring as it couples middleware creation and configuration. All reitit middleware are named -middleware, of type options -> handler -> handler

ikitommi09:08:11

really bad -> not optimal.

Elso11:08:48

["/something" {:get api/something-handler}      `["/:id" {:get api/something-id-handler}`      ["/subthing" {:get api/subthing-handler}]]]

Elso11:08:07

/something matches, /something/asdfasdfasdf/subthing matches, but /something/asdfasdfasdf

ikitommi12:08:26

["/something" {:get api/something-handler}
 ["/:id"
   ["" {:get api/something-id-handler}]
   ["/subthing" {:get api/subthing-handler}]]]
should work

ikitommi12:08:41

there is an issue & open PR to support endpoints in mid-path

Casey20:08:51

I can't seem to find the docs regarding routing syntax when it comes to nested routes. What is the difference between ["" ["/" {:name :root}] ["/sub1" {:name :sub1 }]] and [["/" :foo] ["/sub1"]] When to use "" and when not? And how do you properly add another level deeper (so /sub1/sub2) when you want each level to have its own view?