Clojurians Log v2
reitit
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}))
@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: https://github.com/nilenso/pencil.space/blob/alpha/client/cljs/src/routes.cljs#L43 (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:
(rf/reg-fx
::redirect
(fn [name params query]
(rfe/push-state name params query)))
(rf/reg-event-fx
::navigated
(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
thanks @just.sultanov