This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (1)
- # announcements (31)
- # babashka (9)
- # babashka-sci-dev (36)
- # beginners (72)
- # calva (20)
- # clj-kondo (99)
- # cljsrn (1)
- # clojure (77)
- # clojure-europe (33)
- # clojure-nl (4)
- # clojure-norway (12)
- # clojure-uk (4)
- # clojurescript (23)
- # cursive (2)
- # datascript (5)
- # events (1)
- # fulcro (3)
- # honeysql (3)
- # inf-clojure (82)
- # interop (2)
- # kaocha (10)
- # lsp (15)
- # meander (1)
- # missionary (10)
- # off-topic (22)
- # pathom (4)
- # pedestal (3)
- # polylith (20)
- # re-frame (10)
- # react (4)
- # reagent (4)
- # reitit (27)
- # ring-swagger (1)
- # shadow-cljs (34)
- # specter (3)
- # sql (1)
- # testing (5)
- # tools-deps (22)
- # vim (12)
Hello. I’d like an interceptor to bail to a different handler with a 4xx response if a certain spec is not met. I can obviously do this with a simple
s/valid? check inside the interceptor. However, is there any other way to do this in reitit?
lots of people have compared bidi and reitit, but I'm curious if anyone's combined them. We have most of our HTTP server routes in bidi, and instead of doing the work in one go to replace bidi with reitit, it'd be really nice to be able to specify a whole bunch of new routes using reitit. Anyone tried anything like this, or am I bonkers?
Both create ring handler functions, taking ring request map and returning response map.
You can combine them by calling
(or (bidi req) (reitit req)) or such.
BUT some middlewares are side-effecting, like reading the request body input-stream, so you need to take some care to avoid these side-effects if the first handler doesn't return response. When/if bidi reads the request body stream, reitit (muuntaja) can't read it. If you put reitit first it might work because reitit IIRC only runs the middlewares if we find handler for given request.
Or you could mount reitit handler inside bidi routes, or the other way.
Is there a router other than
linear-router that I can use (in CLJS) to handle conflicting paths? I have a rather small number of routes so lookup performance shouldn't be a concern, and
linear-router is quite costly in terms of emitted JS size and initialization time (seemingly because it uses
Not right now, I think we had a issue or PR testing minimal router to optimize the artifact size.
If you also use reitit.coercion.malli (or the others), it also includes bunch of unnecessary swagger stuff on Cljs side: https://github.com/metosin/reitit/issues/463
Alright. I do use schemas but I've stripped that out of the route definitions in the frontend.
I'm thinking perhaps I could write my own router?
Are there any built-in utility functions that I can use to 'brute-force' matches?
I'd be happy to just go down the list of routes one by one and use the first match
I think you can take linear-router and remove references to trie-router
Or hm, does the linear-router always use trie...
I can't find any issue about this now, but we have talked about this
When trie impl was added, linear-router really just went through list of routes in order: https://github.com/metosin/reitit/blob/5390086d7f1bfcb796466f96836f37710fcaec2b/modules/reitit-core/src/reitit/core.cljc#L139-L178
I'll just steal that code 🙂 thanks
BTW, if you're looking at improving JS performance, I noticed that I could cut router startup time in half by moving the calls to
impl/path-conflicting-routes out into a separate function and calling it in a macro (i.e. at compile time)
Starting the router is reasonably fast out of the box (~100ms on my computer), but for e.g. mobile users speeding it up can make a noticeable difference
Macro compilation time only works if the route tree is completely static value. But it could be useful to provide macro for those cases.
Using simple router instead of building a trie could also make the startup faster
You wouldn't need to provide a macro for it; if you just refactored the code so that users could call the 'precomputable' parts first and then build a router from those, then it'd be easy for users to write their own macro to handle it
Hmm yeah separating static and dynamic parts could be nice way to solve that.
I still don't know. Many parts, like conflicting-paths check etc. would need to be done again when combining those parts. It would get quite complex quickly.