Fork me on GitHub

Hi - trying (and failing) to set the logging level on frontend release builds Currently stuck on ":debug" In a project based on fulcro template Using shadow-cljs - config is largely unchanged from base repo Have read through docs and comments and running the following code

TAOENSSO_TIMBRE_MIN_LEVEL_EDN=:warn shadow-cljs release :main
Have confirmed that this compiles correctly and I'm loading the compiled code but the console output is still populated by DEBUG messages Have also tried amending above to use TIMBRE_LEVEL also not sure if the value needs to be quoted =:warn or =':warn' so basically tried all combinations - no change in behaviour Have also searched through the code for any mention of log/set-level! or other interaction with the timbre package - can't find anything obvious.. shadow cljs 2.16.12 fulcro version 3.5.8 timbre 5.1.2 I'm out of ideas here..


Did you stop your shadow server? Environment variables only affect new processes not existing servers


No, didn't try that - I'll give it a go!


I just added this to the book to clarify:

❤️ 1

Hi fulcro lovers. There is a reason why dr/current-route return [] when the path-segment of the Router contains ["home"] ?

(defsc SideMenu [this props]
  {:ident         (fn [] [:component/id ::SideMenu])
   :query         [[::uism/asm-id ::Router]]
   :initial-state (fn [_] {})}
 (prn (dr/current-route this)) ;; [] on the first render

(defsc Layout [this props]
  {:ident         (fn [] [:component/id ::Layout])
   :query         [{:side-menu (comp/get-query SideMenu)}]
   :initial-state (fn [_] {:side-menu (comp/get-initial-state SideMenu)})}
  (ui-side-menu (:side-menu props)))

(defsc Root [this {:ui/keys [ready?] :root/keys [router] :as props}]
  {:query                [:ui/ready?
                          {:layout (comp/get-query Layout)}
                          {:root/router (comp/get-query Router)}]
   :componentDidMount    (fn [this] (mroot/register-root! this {:app app}))
   :componentWillUnmount (fn [this] (mroot/deregister-root! this {:app app}))
   :initial-state        (fn [_] {:ui/ready?   false
                                  :root/router (comp/get-initial-state Router)
                                  :layout      (comp/get-initial-state Layout)})}
  (when ready?
    (ui-layout (:layout props)
               (ui-router router))))


Not entirely sure, but I think you need to set :route-segment on your router targets. Be aware that a default route target will not behave the same as a route target that is explicitly routed to. Better to explicitly route to your initial leaf node instead of relying on the default. See

❤️ 1

Thanks @UPWHQK562 for you answer. Indeed, all route targets have route-segment set. I have a route targets Home with the route-segment ["home"]


Are you calling change-route! somewhere initially to get to it?


Yep. I use pushy with this code:

(defonce history (pushy/pushy
                   (fn [path]
                     (dr/change-route! app path))
                   (fn [url]
                     (let [path (-url->path url)]
                       (if (routable-path? app path)

(defn start-history! []
  (pushy/start! history))

(m/defmutation init-ui [_]
  (action [{:keys [state]}]
          (swap! state assoc :ui/ready? true)))

(defn start-routing!
  "Init the routing system"
  (comp/transact! app [(init-ui nil)]))


If you look in Fulcro Inspect, what do you see at the path



I have [:component/id :]


be careful with registered roots. not sure what you're doing exactly, but the routing ns relies on the queries (which are dynamic) of the live all composing to root, and some functions only work in certain circumstances/contexts.


READ CAREFULLY the docstring of current-route...that one is particularly unreliable due to how it has to work.


Also note that each router has a state machine, and unless those state machines are started and running and routed then there will be no active route, even though something will render


routers need to be able to render a first frame, but the app mount will not have run transactions yet, so there won't be any state machines running (unless you set up app state completely and did routing before mounting).


Thanks @U0CKQ19AQ for your precisions


The dyn routers have some really nice features, but there are some rough edges. The arbitrary composition has some tensions with other concerns, like knowing what route you're "on" (the answer may be more than one, and the URI can only express one)...just as an could embed 6 routers in 6 different areas of the same screen, all controlling subroutes for that sub-area


so "current route" is a bit of a hit or miss thing depending on how you use the system


This code in fulcro-rad-kvstore is fundamentally broken. These functions will, depending on the setting, be returning either maps or core.async channels and the callers do not make any adjustments to account for that duality. If you pick channels you will straight up get an error.


You have control over the calling code. Perhaps just stick to maps. The core.async channels are more a special case where you want the kvstore to be within the browser. A copy of the RAD Demo is part of the repo and just uses maps. We could I suppose simplify things and only ever return maps. I don't know how much this repo is actually used - perhaps a good use case is another remote for session data. What are your needs for fulcro-rad-kvstore ?


Having the control over calling code does not resolve the bugs that are internal to the library itself i.e. the code within the library calls a function that can return either a map or a channel, depending on the settings, but it will fail if channel is returned. The use case where i’ve encountered this is when I tried using fulcro-rad-kvstore in CLJS with IndexedDB as backend. This function returns either map or chan based on chan-fns? parameter. The resolver calls entity-query function here which calls one of these dual functions here: . entities here can be a coll or chan based on chan-fns? chosen earlier. Immediately in the next line entities is used in mapv which in case of chan value fails with error that a chan in not sequable. So that makes library broken when using chan-fns?=true which is the only thing available to CLJS which makes using this library in CLJS a non-starter.


I wrote com.example.ui.landing-page-2 to test browser-based. You might like to change com.example.ui so that it requires:

[com.example.ui.landing-page-2 :as lp]
then run the demo app.


I found that the underlying konserve functions were wrapping results when using IndexedDB, whereas they didn't with any other kv-store, so I never proceeded much with browser based. If you run the demo app with the -2 landing page there's just a page of buttons to press, so you can gauge for yourself.


As I remember it results are shown in the browser console.


So far I have found 3 bugs trying to bring this to life: • wrong tempid unwrapping • incognito doesn’t correctly deserialize UUIDs (this lib->konserve->incognito) so when you try to load any entity the ident matches nothing in the database • aforementioned type error because chan gets passed into mapv


The tempid unwrapping should just be that the uuid is created on the client (b/c that's what is inside a fulcro tempid). So unwrapping just means getting the uuid out again. If it is more complicated than that then it might be b/c I copied code from the Datomic version of this. I can't remember incognito. Good that you are trying to bring it back to life. You are welcome to take over maintenance as I've never been a user myself.


In the interest of not spreading misinformation I have deleted a previous post It described how running the release command manually changed the logging level I made a mistake - it didn't work I had overlooked the following line of code at the start of my init method

(when-not goog.DEBUG (log/set-level! :warn))
and all my previous builds ran with this in place so my conclusion was void when I remove this line and re-build the release, and I have tried it a lot of different ways - the debug logging returns So I have a workaround by forcing the logging level (as above) but this is unsatisfactory as I am still unable to get the environment variables to have the desired effect and most frustratingly I do not know why....


quick update I wondered if the cache might have anything to do with this I removed what I thought was the cache folder for the release build but that didn't seem to change anything I then just removed the entire release build folder from the .shadow-cljs directory Now things seem to be behaving debug logging in dev, standard logging in release One question - would you expect the logging level on the release build to drop below "debug" by default?


don't understand your question


I would expect a release build to do whatever you tell it...but caching could affect a build that needs to run macros to elide code


so a pre-built file that has logging might not be recomiled


A fair challenge - question lacked enough context on reflection I was able to check it myself. The following detail may be helpful to others who are making this discovery. I cloned a new copy of fulcro template and ran a :dev build - has debug logging Stopped the shadow server and created a release build - still has debug logging by clearing the "release" folder after each step I can control the debug level with the environment variable on the command line if I do not supply an env variable the logging level remains at debug Thank you Tony for your input, it was central to helping me understand what was going on here