Fork me on GitHub

Hi folks, does anybody have experience or idea of how I can implement something like react's hashHistory/HashRouter in fulcro? I want to create a frontend-only page and use it in gh-pages.


You mean react-router's HashRouter?


Have a look at So you need the fulcro routers (section 20, or was it 21 in the book), and then make a helper that does a route change and url change, and put listeners. Fulcro RAD has some examples based on the path of the URL, but there's nothing special. You could use the hash very similarly


I haven't actually used react-router v4–v6, only v3. But my impression is that the fulcro's implementation is much in the same spirit as v5. That is, the router (or Route in react-router) components are intermixed in the ui component tree


Just getting my head around this too, though I don't need it quite yet (all our PoC UIs are still separate projects)


thanks I will check it out, I was looking at rad and maybe if was possible to set the route prefix as # it should work, I think.


And tweak the listener too, as the RAD version only looks at the path and params, skiping the hash


Err, I mean path and search


Hm, does that have any listeners for URL changes?


Ah, it checks it at The state machinery is still unknown to me. I can't read it that happens only at init, or does it check it later too


I was searching


Hey I managed to draft something here I had to "fork" pushy to use path-prefix


👋 not sure if this is the right spot, but I have a question about fulcro’s guardrails. Is it possible to get runtime access to whether or not guardrails is enabled? I’d like to do some extra “type” checking at runtime that is more complex than a spec could capture (but only when guardrails is enabled).

👋 1

I think you can just (System/getProperty "guardrails.enabled") , right?


Thanks! I should have stated that I’m in ClojureScript but that gives me something to search the repo for! I’ll update if I figure it out.


so, most of the decision logic on putting GR into your runtime happens at macroexpansion…I don’t know if there is a trivial way to detect it at runtime, though you could make a macro that emits the system property to source as a constant.


(defmacro gr-enabled? [] ~(System/getProperty "guardrails.enabled"))


might do it


the problem then is compiler caching at dev time…the result of the macro on a file that doesn’t get recompiled


Appreciate it! With your last comment are you saying that if you changed the system property it could still be cached to its previous value in the compiled code?


or, if an incremental compile was done (say you stopped the compiler and restated it w/diff gr enabled state)…the files that don’t get recompiled would have the stale value


thanks for the clarification! that would be fine for my use-case so i’ll go down this path 👍


GR proper has the same concern…you could technically get a mix of instrumented/non-instrumented code in such a transition


but the alternative is to add overhead at runtime to even non-instrumented code…whihc is unacceptable

👍 1

that makes sense. since GR proper has the same concern do you think it makes sense to add the enabled macro to core? I could submit a PR if you’d like.


try it for yourself first, and yeah, if it works ok, I’m fine throwing it into core

👍 1