reitit 2022-03-29 | Slack Archive

onetom02:03:53

When an exception occurs, all I get in the response body is {:type "exception", :class "java.lang.ClassCastException"} How can I reveal the ex-data of the exception too?

onetom02:03:46

my router options look like this:

{:data
   {:muuntaja   muuntaja-instance
    :middleware [[svc-middleware svc-ref]
                 segment/middleware
                 ginoco.middleware/cors
                 reitit.ring.middleware.parameters/parameters-middleware
                 muuntaja/format-negotiate-middleware
                 muuntaja/format-response-middleware
                 :handle-exception
                 muuntaja/format-request-middleware
                 reitit.ring.coercion/coerce-exceptions-middleware
                 reitit.ring.coercion/coerce-request-middleware]}

   :reitit.middleware/registry
   {:get-jwt-claims   jwt-claims-from-auth-header-middleware
    :handle-exception (exception/create-exception-middleware
                        (merge exception/default-handlers
                               {::exception/wrap
                                (fn [handler ^Throwable ex req]
                                  (send-ring-exception-to-sentry ex req)
                                  (handler ex req))}))}}

onetom02:03:51

is this the correct order of middlewares? 1. (exception/create-exception-middleware (merge exception/default-handlers ... 2. reitit.ring.coercion/coerce-exceptions-middleware 3. reitit.ring.coercion/coerce-request-middleware

Linus Ericsson11:03:59

Reitit-pedestal confuses me a bit. I was initially thinking that it would use pedestal interceptors but it uses muuntaja interceptors which seems to be a great speedup and other things, so I really understand the decision here. We currently use pedestal interceptors (and also the integration with core.async for some asynchronous things). We also use interceptors without pedestal web requests (for some parts of websocket message handling). If we would like to use reitit routes (on both server- and client side) and not convert all the interceptors to some other format just yet. The reitit-pedestal is quite a small package, would you recommend to just rewrite the parts that are specific to muuntaja and instead trying to use pedestal interceptors?

Linus Ericsson12:03:28

or is it just to start using sieppari with core.async (I understand there is an expectation to restructure data in :requests and :responses, right?)

Linus Ericsson12:03:06

found this: https://github.com/metosin/reitit/tree/master/examples/pedestal/src/example

pmooser12:03:56

I'm using reitit for frontend routing in my application. I'm changing our URL scheme so that what used to be "/" is now "/-/", and I'm trying to do this in a way that propagates query params provided to the first route to the second one. Is there an easy way to do this ? Following the typical front end easy controller example that stores the last match in an atom, at the point at which the controllers run, the swap! hasn't finished yet, so effectively the query params are invisible to the code at this point ... but maybe there's some more direct (and less dumb than what I'm doing) way to get at them?

pmooser12:03:14

I'm not explaining it well, but in the :start fn of my legacy route, I effectively do a reitit.frontend.easy/push-state that ends up navigating to the new URL.

pmooser12:03:12

To answer my own question, I can list the query params I want to be propagated in each route manually and propagate them, or I can invent some other out-of-band mechanism that saves them at the beginning of the on-navigate function, before I apply the controllers.

2022-03-29

Channels