This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-09-27
Channels
- # announcements (2)
- # asami (25)
- # babashka (124)
- # beginners (46)
- # calva (55)
- # cljdoc (70)
- # clojure (68)
- # clojure-australia (2)
- # clojure-dev (63)
- # clojure-europe (38)
- # clojure-nl (1)
- # clojure-spec (1)
- # clojure-uk (8)
- # clojurescript (56)
- # community-development (4)
- # conjure (1)
- # copenhagen-clojurians (1)
- # core-async (1)
- # cursive (3)
- # datahike (5)
- # datomic (183)
- # depstar (2)
- # figwheel-main (10)
- # fulcro (20)
- # honeysql (2)
- # hyperfiddle (1)
- # integrant (68)
- # jobs (6)
- # jobs-discuss (5)
- # juxt (1)
- # malli (13)
- # off-topic (8)
- # pathom (2)
- # rdf (10)
- # reagent (11)
- # remote-jobs (1)
- # rum (1)
- # shadow-cljs (69)
- # spacemacs (1)
- # sql (5)
- # tools-build (51)
- # tools-deps (6)
- # xtdb (24)
Hi Tony! I am looking into preventing the https://book.fulcrologic.com/#warn-uism-sm-not-in-state warning when I change-route
in my app's init
function. This is what I have now and it is broken:
(app/set-root! app Root {:initialize-state? true})
(dr/initialize! app) ; BEWARE: "async"!
(dr/change-route! app ["all"])
and that's because dr/initialize!
is not immediate since it only submits a transaction. The obvious solution is to replace the direct call to change-route!
with issuing a mutation that does the same. My question is: is that what you would do or is there a better way? But fulcro-rad-demo does just ☝️ So perhaps I should just ignore the warning?? Thank you!Yeah, it is a bit of a chicken-and-egg problem. I really should tune up the underlying code...I've really left no easy way for you to not get a warning on startup. Most likely the initialize!
function should just be synchronous.
Ok, thank you!
Great question. It has a relatively narrow use-case that is also solved by React Context: having something from "above" that you don't have to explicitly query for that, when it changes, causes a refresh. I use shared props in the i18n lib to share the current translations and locale. If those change, then everything needs to refresh. That's about the only place I ever use it TBH. Another potential place is for things like auth/current user session info.
I typically prefer having the explicit join in my query to the data I want...fewer places to go looking for it. But for i18n having to add [::i18n/current-translations '_]
to every component (including those that would otherwise not have a query) is ridiculous....using an atom is tractable as well, but it requires that you remember to force a global root render whenever you change that atom (which you can do with a watch) so it's all up to your preferences really.
In some ways the atom-with-a-watch is superior, other than installing the watch on hot reloads needs some attention to detail...but updating that global state is less opaque. Shared was part of the original Om Next library, and I've mainly carried it along "because it was there"
React Contexts can be defined at arbitrary depth, and shadowed, but based on the docs I understood that shared state is strictly defined at root level. Did I understand correctly?
I could definitely see a use for react tree scoped/bound "globals", in addition to lexically scoped globals
If not elsewhere, at least in a component showcase/test page, where you'd perhaps want to have all kinds of versions visible side by side, while normally they would follow some global flag
Being global with a big G was one of the intractable obstacles I often found with reagent and re-frame
So, some things are just naturally global: The current translations/locale. The current user/session. The current URL. The current UI route.
But, most things are not, and I agree that shared
is not sufficient or appropriate for that. React Context didn't exist when it was created. You can definitely use React context, and it is the scoped facility for this kind of thing in React. I do not implement something like it, because it is already there.
Ideally we'd be able to use dynamic vars, which is the Clojure solution to this kind of thing...but unfortunately the rendering is an async kind of thing where scoped clj bindings are not in effect when you think they are.
That said, I would not object to a reasonable wrapper around it (React Context) that made it appear more natural, even though it is pure React/js
Yeah, indeed the language provided mechanisms can't work when react does it's thing however it wants to. I'll see how the current hooks support is done to see how I could access the useContext hook
Ah, I see. I can just call js/React and everything it provides as if I was in the usual render function
And even the doc string for update-shared!
mentions that I should consider contexts instead of shared state