reitit

https://cljdoc.org/d/metosin/reitit/ https://github.com/metosin/reitit/
heyarne 2020-03-12T11:47:08.050100Z

So I'm using reitit.ring.coercion with retitit.coercion.spec and I noticed an inconsistency in query parameter handling: Let's say I have a spec like (s/def ::numbers (s/coll-of int?)) and I use that as query param, the swagger ui will render a ui that looks like the screenshot which is cool and all, but the parameter will be concatenated in the url, like numbers=1,2,3 instead of the expected format numbers=1&numbers=2&numbers=3

heyarne 2020-03-12T11:51:06.050400Z

heyarne 2020-03-12T11:53:03.051100Z

The solution seems to be defining collectionFormat=multi as noted here: https://swagger.io/docs/specification/2-0/describing-parameters/#array-and-multi-value-parameters

heyarne 2020-03-12T11:53:45.051600Z

Can I describe this anywhere? Should I open an issue?

ikitommi 2020-03-12T11:54:56.052100Z

I think the default should be the one that ring-parameters supports.

ikitommi 2020-03-12T11:55:05.052400Z

issue (ja PR) welcome!

ikitommi 2020-03-12T11:56:17.053600Z

This should work too: (s/def ::numbers (st/spec {:spec (s/coll-of int?), :swagger/collectionFormat "multi"}))

ikitommi 2020-03-12T11:56:54.054300Z

e.g. all keys with swagger ns are pushed to swagger docs. didn’t test that, but recall it’s so 🙂

👍 1
ikitommi 2020-03-12T12:39:01.055500Z

Do people have comments on default exception handling? The current “don’t log, don’t tell users too much about errors” is not the friendliest detault (with reitit-ring).

ikitommi 2020-03-12T12:39:10.055800Z

copying this from projects:

(exception/create-exception-middleware
  (merge
    exception/default-handlers
    {::exception/wrap (fn [handler ^Exception e request]
                        (log/error e (.getMessage e))
                        (handler e request))}))

dharrigan 2020-03-12T12:49:45.056300Z

Personally, I would like to know when an error happens, even at an Info level.

kszabo 2020-03-12T12:58:53.057Z

yeah, the lack of built-in logging support has been a bit of a pain

kszabo 2020-03-12T12:59:13.057400Z

but of course it’s hard to standardize with all of the options available :)

kszabo 2020-03-12T13:00:40.057800Z

(defn logging-compile
  [logger
   {{:keys [enabled? log-start-fn log-end-fn log-error-fn]
     :or   {enabled?     false
            log-start-fn default-log-start
            log-end-fn   default-log-end
            log-error-fn default-log-error}}
    :logging} _]
  (when enabled?
    {:enter (fn logging-interceptor-enter [ctx]
              (let [ctx' (add-start-nano ctx)]
                (when log-start-fn
                  (log-start-fn logger ctx'))
                ctx'))
     :leave (fn logging-interceptor-leave [ctx]
              (when log-end-fn
                (log-end-fn logger ctx))
              ctx)
     :error (fn logging-interceptor-error [ctx]
              (when log-error-fn
                (log-error-fn logger ctx))
              ctx)}))

(defn logging-interceptor
  [logger]
  {:name    ::logging
   :spec    ::logging-interceptor
   :compile (partial logging-compile logger)})

kszabo 2020-03-12T13:00:51.058100Z

something like this could be added, that is function-based

kszabo 2020-03-12T13:01:45.058600Z

might even leave out the defaults, to be completely free of logging deps

juhoteperi 2020-03-12T13:28:06.060Z

Separate ns with clojure.tools.logging handlers would work in many cases

heyarne 2020-03-12T14:16:10.060100Z

@ikitommi where would be the place to fix this? here? I'm not very familiar with the codebasehttps://github.com/metosin/spec-tools/blob/master/src/spec_tools/swagger/core.cljc#L59-L63

kszabo 2020-03-12T14:20:55.061200Z

yep, that’s what we use as well, but I think it’s application/endpoint dependent what/how you want to log. Though thing to tackle generally

ikitommi 2020-03-12T14:32:12.061300Z

looks like it. You should check for the parameter type, this applies only for query params, right? See https://github.com/metosin/spec-tools/blob/master/src/spec_tools/swagger/core.cljc#L76

worlds-endless 2020-03-12T15:54:53.063300Z

I'm looking for a clean back-button interception method the ask confirmation when they are leaving unsaved data, and doesn't make changes to the history stack or use reitit controllers if they say "no." Surely someone here has dealt with this?

worlds-endless 2020-03-12T18:16:29.064800Z

Standard javascript solutions want a window.beforeunload call with a conf; I'm not sure how this will behave with SPA, but other solutoins with react-router does the job, so it would make sense to have this in reitit's provenance