This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-04
Channels
- # babashka (17)
- # beginners (82)
- # calva (42)
- # clj-commons (9)
- # cljdoc (2)
- # cljsrn (3)
- # clojure (142)
- # clojure-europe (12)
- # clojure-nl (1)
- # clojure-sg (1)
- # clojure-uk (14)
- # clojurescript (22)
- # community-development (3)
- # cryogen (12)
- # cursive (15)
- # data-science (13)
- # datomic (11)
- # deps-new (8)
- # emacs (3)
- # fulcro (31)
- # gratitude (7)
- # holy-lambda (8)
- # honeysql (6)
- # introduce-yourself (1)
- # jackdaw (11)
- # jobs-discuss (7)
- # kaocha (1)
- # malli (8)
- # other-languages (9)
- # pathom (14)
- # pedestal (1)
- # polylith (3)
- # portal (12)
- # re-frame (3)
- # react (3)
- # reagent (4)
- # releases (3)
- # reveal (7)
- # ring (11)
- # shadow-cljs (17)
- # specter (3)
- # sql (1)
- # timbre (2)
- # tools-deps (122)
- # xtdb (18)
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.
sorry, yes
Have a look at https://github.com/fulcro-community/guides/blob/tutorial/advanced-min-fulcro/modules/tutorial-advanced-minimalist-fulcro/pages/index.adoc#binding-the-route-to-the-url. 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
I will follow a "easier" way and try to modify this into a hash https://github.com/fulcrologic/video-series/blob/master/src/app/routing.cljs
Ah, it checks it at https://github.com/fulcrologic/video-series/blob/817969602a31aee5fbf546b35893d73f93f1d78c/src/app/client.cljs#L125. 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
interesting
I was searching
Hey I managed to draft something here https://github.com/rafaeldelboni/stasis/blob/main/src/stasis/routing.cljs 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).
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.
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