This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (4)
- # beginners (68)
- # boot (3)
- # business (20)
- # cider (39)
- # cljs-dev (7)
- # cljsjs (1)
- # cljsrn (12)
- # clojure (122)
- # clojure-brasil (2)
- # clojure-italy (7)
- # clojure-nl (5)
- # clojure-spec (60)
- # clojure-uk (41)
- # clojurescript (67)
- # cursive (7)
- # datomic (13)
- # emacs (6)
- # figwheel-main (18)
- # fulcro (40)
- # garden (3)
- # graphql (2)
- # hyperfiddle (4)
- # jobs-discuss (10)
- # lein-figwheel (5)
- # leiningen (12)
- # luminus (6)
- # mount (3)
- # off-topic (52)
- # portkey (2)
- # re-frame (1)
- # reagent (6)
- # reitit (24)
- # shadow-cljs (15)
- # sql (3)
- # tools-deps (12)
hi there! I'm starting a new project, and I've used bidi in the past, but i'm interested in reitit
with bidi, I use it very simply - usually have a tree of routes which return keywords, on the back end these are matched to a large map of type
kw->handler-fn, on the front end I use accountant to dispatch events with re-frame
I use it this way because, putting back end specific things like handler functions in the route map means I would have to duplicate my routes for the front end
is there anyone with overlapping front/back-end routes using reitit who can show me how they do it? just replicate routes?
the custom expander looks very similar to what I achieved with bidi/my own keyword matching middleware
Your welcome. As this is a quite common case, there could be a new option
:reitit.ring/handler-registry in the ring-handler doing this without the expander boilerplate? There is already
:reitit.middleware/registry and (and
:reitit.interceptor/registry) for expanding keywords into middleware/interceptors.
yes, that's the way bidi does it - a third optional function which gets the result of the match and you're free to dispatch as you like
haven’t used that feature with bidi, but I guess it dispatches to the function at request-time? with reitit, the expansion happens at router creation time.
the expander example can emit whole endpoints, with route data, methods etc. we want to validate those and fail fast if there is a error. and the perf is much better when the route tree is compiled forehand.
actually, for ring, it should be something like
:reitit.ring/name-registry as it’s not about handlers. Hmm.
hmm. i've enjoyed the simplicity of just nesting functions where the data from each is passed down the line.. eg, just match a keyword, the handler has middleware to see if it accepts a get or a post... looks like reitit is much more up-front about a lot of things which I would just kick down the line
still comparing the two to see which would fit my mental model more.. performance aside.
i like having a very bare-bones route map i can refer to, but it looks like the expansion takes care of that
you can do that too. just mount a handler into the path, it accepts all method. you need to route the method etc. yourself then.
looks like it won't be too much of a step to drop reitit in and then gradually conform to it haha