This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # announcements (11)
- # asami (6)
- # aws (26)
- # babashka (17)
- # beginners (119)
- # bristol-clojurians (7)
- # chlorine-clover (2)
- # cider (3)
- # circleci (1)
- # clj-kondo (10)
- # clojure (127)
- # clojure-australia (3)
- # clojure-dusseldorf (5)
- # clojure-europe (135)
- # clojure-france (5)
- # clojure-nl (8)
- # clojure-uk (6)
- # clojurescript (103)
- # clojurewerkz (1)
- # crux (22)
- # css (2)
- # cursive (5)
- # datalog (5)
- # datomic (36)
- # emacs (3)
- # events (2)
- # figwheel-main (3)
- # fulcro (1)
- # graalvm (3)
- # helix (31)
- # jobs-discuss (4)
- # leiningen (1)
- # london-clojurians (1)
- # malli (17)
- # off-topic (2)
- # parinfer (10)
- # portal (1)
- # re-frame (48)
- # reitit (2)
- # reveal (12)
- # shadow-cljs (3)
- # sql (3)
- # tools-deps (4)
- # vim (4)
Sounds nice, I'm doing that too (requiring helix.core helix.dom) in almost every views.cljs (and helix.hooks for about 50% of these files). In comparison reagent is always imported once since everything is in reagent.core
Maybe more clearly, is there some reason you’re creating elements but not defining components using defnc?
To your point Lucy, there was a deliberate attempt to be a bit more organized. It’s necessary to split anything that depends on react-dom from core to allow ease of use with things like react-native.
@lilactown hey, what you think about adding
declare statements in
helix.dom to allow static analisys to known about the variables defined by the macros? that's what Fulcro does: https://github.com/fulcrologic/fulcro/blob/develop/src/main/com/fulcrologic/fulcro/dom.cljs#L17-L30, I remember this being add as stubs on Cursive, but its not working on my end
That sounds good, anything that helps people with editors that do static analysis is +1 for me
@lilactown It is less about not having to require the additional namespace and more about having to remember in some context to keep switching the namespace prefix (or not include one if you are referring, which I try to avoid). It is much easier to just do
d/<> than to have to remember that the outer two are from helix.core instead. I have found my self making this mistake a lot.
That said, there are cases where I am not defnc'ing in some namespace, because I am integrating helix into a big old hoplon code base. My defnc components are defined else where and then slowly integrated into the hoplon. In those cases, I generally, only need core for $, but occasionally mounting with some wrapper that doesn't really belong to the component is useful. I can of course use $, but part of my preference for the dom helpers is that they mirror what we are already doing in hoplon and it will be easier for me to teach people with them.
In general, like I said, it is minor, but just seems convenient and doesn't cause any issues with keeping react-dom separate (which makes perfect sense to do).
I will just add, that I started with just vanilla react and every time I ran into a little oddity, I thought about how I would fix it, then I went and looked at what helix did with it. Every time I found it was exactly what I would want to do, but just done more robustly. Super happy that helix exists.
Hi, I really like the idea of reseda or any other library which offers a event/subscribe model for the application (like re-frame in reagent bases system). However it’s not clear to me how you would integrate this with 3rd party library which offer ther own state via hook. In my case this would be react-fire for firestore. This library basically offers useDocument hook which gives you access to a specific db document (including offline support, local caching etc). Would you copy the state to the global store managed by reseda? Just manage the state which is not in firebase and use the document state in the componend where needed?
Yeah maybe yes. I wonder if there is prio art on keeping the necessary information in sync.
I think if they change differently, they belong to different stores. Both for semantics and for performance.
I don’t know react-fire but if there’s a lower level api that you could wrap in a “watchable” then reseda can wrap that.
Of cause you can use
useEffect to monitor the return value of
(useDocument "some-id") and then
(dispath [:document-updated "some-id" the-new-value]) but I’ve got the feeling that will get you in trouble eventually
There’s also https://github.com/CSFrequency/react-firebase-hooks/tree/master/firestore but I didn’t look into the latter.
What I found interesting was the support for Suspense. How does this play together with reseda?
Regarding your initial question you could always use the firebase sdk which is based on promises. So my question is kind of more fundamental how to integrate 3rd-party hooks with reseda and whether that makes sense at all.
I like the idea of having the effective state in a single, place. Just for being able to explore it. e.g.
Well, reseda store doesn’t really know anything about what’s inside. If you use a Suspending to wrap a promise, for reseda it’s still a value. It’s react that deals with the Suspense.
Looking at the react-fire example, you can have a reseda powered Suspending as a sibling (or child) of the Burrito element and react will wait for both to load before it renders.
Suspending wraps a promise which is single shot so I’m not sure how can you get streaming data though.
Like, real time - you’d need to watch a stream of changes and swap! Things into your atom as they change.