Fork me on GitHub

The reitit > 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:

 [["/data/somebase*" ::somebase]
  ["/data/anotherbase*" ::anotherbase]
  ["/{*path}" ::catch-all]]
 {:conflicts nil}) ;; => works
 (r/router [["/data/somebase*" ::somebase]
            ["/data/anotherbase*" ::anotherbase]
            ["/{*path}" ::catch-all]]
           {:conflicts nil})) ;; => EXCEPTION
I guess this is because http/router calls r/router internally… 💡 And I guess is this what the :router in the router data is for


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


> 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