@aaron51 would this work as a schema?

(s/constrained
  {(s/optional-key :a) s/Int
   (s/optional-key :b) s/Int}
  (fn [{:keys [a b]}] (not (and a b)))
  'a-or-b)

middleware module mostly done, will rethink some design decisions and get a internal review. module ships with the followinf middleware: • reitit.ring.middleware.exceptions/exception-middleware <= c-api exception handling, polished • reitit.ring.middelware.multipart/multipart-middleware <= multipart integrated, with coercion & swagger • reitit.ring.middleware.muuntaja/... <= the 4 muuntaja middleware, require :muuntaja key in the route data (not sure if this is the best way to do this)

here’s a c-api like app, with upload, download, exception handling & few api endpoints: https://github.com/metosin/reitit/blob/6bb233d87afea22e8290081327dd2335058aaf83/examples/ring-swagger/src/example/server.clj

… and the reitit.ring.schema contains the Schemas for the multiparts

there is still the ring.middleware.param/wrap-params. At some point, that could be lifted too, the form param parts to Muuntaja ja the query-parameters into a own middleware. the keyword-params is not needed as reitit coercion does the string->keyword transformation already.

hello 👋. we’re using pedestal on the server and are now adding client-side routing to our cljs app. Our app has github-style urls, so e.g. /:profile-handle also matches our :create-article route at /a. Does reitit not respect ordering of the routes like pedestal does to resolve this or am I missing something?

@mkvlr I’m not sure I understand what you you mean. But, if you have multiple routes that have the same path template, e.g. /:profile-handle" and /a - by default, reitit sees those as conflicting and fails to create a router. You can disable the conflict resolution with router option {:conflicts (constantly nil)} forcing the router implementation be :linear-router, taking the first match.

yes, we do disable conflict resolution

I think our issue is that appending url params changes what gets matched

e.g. (r/match-by-path router "/a") != (r/match-by-path router "/a?profile-id=123")

is that expected? How can we deal with optional params like that?

oh, the query-parameters should not be there. the match-by-path only takes the path.

there is the reitit-frontend module, which does splitting of the query-params.

wait a sec.

doh, I guess that’s why it’s called match-by-path…

that because in the backend, the query-params are passed separately, in browser, need to split.

https://github.com/metosin/reitit/blob/master/modules/reitit-frontend/src/reitit/frontend.cljs

thank you

there are helpers for the browser, a sample project: https://github.com/metosin/reitit/tree/master/examples/frontend

just returning from vacation, haven’t talked with @juhoteperi, who has been doing that. no docs yet, but we have been using those for 1y+ I believe.

also we’d like to migrate to reitit gradually, so still support our usages of pedestals url-for. How do you recommend handling optional query-params for this?

(defn path
  ([route params]
   (let [required-params (:required (r/match-by-name router route))
         route (r/match-by-name router route params)
         query-params (apply dissoc params required-params)
         route-with-query (assoc route :query-params query-params)]
     (r/match->path route-with-query query-params))))

this is what we’re currently doing

so matching without params to find out the required path-params, so we can add the rest to the query-params.

ah, I see, so reitit wants any optional query-params to be defined as well

you can add any query-params to the request, just the defined ones get copied into :parameters

how does the url-for work in pedestal?

it just takes on params hash, whatever isn’t defined in the route in path-params gets added as a query param

but I think I’ll figure it out using your pointers

thanks a lot for your help!

got it to work using reitit-frontend 🙏