Fork me on GitHub

Hello guys, ok I have a very weird error message when I run my with reitit. This happened when I import reitit.ring or reitit.core. The message is: "Exception in thread "main" java.lang.RuntimeException: Unable to resolve symbol: qualified-keyword? in this context, compiling:(reitit/trie.cljc:317:14)" So, I'm just trying to run a basic ring app with jetty using reitit. This is my core:

(ns comment.core
  (:require [reitit.core :as r]
            [reitit.ring :as ring]
            [ring.adapter.jetty :as jetty]))

(def routes
  [["/ping" {:get (fn [_] {:status 200, :body "ok"})}]])

(def router
  (ring/router routes))

(def app
  (ring/ring-handler router))

(defn start []
  (jetty/run-jetty #'app {:port 3000 :join? false}))
My app crashes because of one reitit dependecies. I cannot figure out what's the problem.


@believelody my guess is that you are using Clojure 1.8 or earlier. qualified-keyword? was introduced in Clojure 1.9.0


@ikitommi oh my god you right! Thanks a lot, now everything is okay!


I have a route like this: (it currently doesn’t do anything). But the idea is: • If someone lands on this page directly, I’d want to run some function to determine some boolean, if it’s false, render some other view which is not the :view • If I manually dispatch to this route, it can still run that function, but it must render the default :view


What is the correct way to achieve this? Since in reitit, the route is always tied to a particular view, I can’t decide one way or another. Is it alright to check the app-db here and dispatch (redirect) to another route in :start?


I think you can rewrite your event ::navigated and add some business logic something like this:

  (fn [name params query]
    (rfe/push-state name params query)))

  (fn [{db :db} [_ new-match]]
    (if-not (get db :some-flag) ;; e.g. check user authenticated/authorized or another your business logic
      {::redirect ::to-your-default-view}
      (let [current-route (:current-route db)
            controllers   (rfc/apply-controllers (:controllers current-route) new-match)
            new-route     (assoc new-match :controllers controllers)]
        {:db (assoc db :current-route new-route)}))))


Or you can just create a subscription for your business logic flag and use it in a wrapper component to render the required component


yeah, the second is what I was thinking


I didn’t consider the first one, that might actually be cleaner since there’s really only 1 default fallback state and not many