This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-10-02
Channels
- # announcements (13)
- # babashka (42)
- # beginners (29)
- # calva (39)
- # cider (15)
- # clerk (10)
- # clojure (67)
- # clojure-europe (18)
- # clojure-hungary (2)
- # clojure-nl (1)
- # clojure-norway (12)
- # clojure-uk (7)
- # clojuredesign-podcast (14)
- # clojurescript (19)
- # datalevin (1)
- # datascript (5)
- # emacs (4)
- # events (2)
- # fulcro (5)
- # graalvm (5)
- # hyperfiddle (23)
- # incanter (3)
- # jobs (2)
- # lsp (8)
- # missionary (15)
- # off-topic (45)
- # portal (41)
- # practicalli (1)
- # re-frame (3)
- # reitit (6)
- # releases (2)
- # remote-jobs (1)
- # sci (1)
- # shadow-cljs (35)
- # solo-full-stack (8)
- # tools-deps (4)
I first asked this in #pyramid but I think it's more of a re-frame user question. You can /s/pyramid/datascript/ or doxa or your normalized db of choice.. How are you all using pyramid in frontend apps (perhaps using re-frame) where a component needs some entity, but also that entity's relationships? It seems like all my components have to subscribe to the whole db, so they can get a handle on it to pull out the data they need. Is there a pattern you've find that works well? Like perhaps use pyramid in the rf/reg-sub to yoink out all the needed data on a per-component basis? Or is it better for the views to subscribe to multiple entities in the db?
> It seems like all my components have to subscribe to the whole db, so they can get a handle on it to pull out the data they need. Create a sub that receives all the necessary instance-identifying information and retrieves that instance from the db. Then use that sub in all your components.