Fork me on GitHub
#reitit
<
2020-03-12
>
heyarne11:03:08

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

heyarne11:03:45

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

ikitommi11:03:56

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

ikitommi11:03:05

issue (ja PR) welcome!

heyarne14:03:10

@U055NJ5CC 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

ikitommi14:03:12

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

ikitommi11:03:17

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

ikitommi11:03:54

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

👍 4
ikitommi12:03:01

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

ikitommi12:03:10

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))}))

dharrigan12:03:45

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

kszabo12:03:53

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

kszabo12:03:13

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

kszabo13:03:40

(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)})

kszabo13:03:51

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

kszabo13:03:45

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

juhoteperi13:03:06

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

kszabo14:03:55

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

worlds-endless15:03:53

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-endless18:03:29

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