The reitit https://cljdoc.org/d/metosin/reitit/0.6.0/doc/advanced/composing-routers: > Nesting routers is not trivial and because of that, should be avoided. For dynamic (request-time) route generation, it’s the only choice. For other cases, nested routes are most likely a better option. Should the nested routes there be “dynamic routers”?

Is it possible to combine the interceptor http.router with a set of composed routes, where those composed routes have a hand coded set of specialised routers? And then, will those nested routes be able to use both generic top-level and route-level interceptors? Are routers composable like this?

hmm ok looks like it’s not:

(http/router
 [["/data/somebase*" ::somebase]
  ["/data/anotherbase*" ::anotherbase]
  ["/{*path}" ::catch-all]]
 {:conflicts nil}) ;; => works

(http/router
 (r/router [["/data/somebase*" ::somebase]
            ["/data/anotherbase*" ::anotherbase]
            ["/{*path}" ::catch-all]]
           {:conflicts nil})) ;; => EXCEPTION

ahh I need to not mix up :router opts with :router route data…

looks like :router route data isn’t used without extension https://cljdoc.org/d/metosin/reitit/0.6.0/doc/advanced/composing-routers#nesting-routers

> That didn’t work as we wanted, as the nested routers don’t have such a route. The core routing doesn’t understand anything the :router key, so it only matched against the top-level router, which gave a match for the catch-all path. I don’t understand this bit… The example goes on to define a recursive-match-by-path function but presumably for this to work in a real webserver we also need to call this recursive-match-by-path from the appropriate Router protocol function match-by-path