This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-11-24
Channels
- # announcements (1)
- # asami (10)
- # aws (1)
- # babashka (1)
- # beginners (105)
- # cider (13)
- # cljsrn (6)
- # clojure (42)
- # clojure-australia (4)
- # clojure-dev (7)
- # clojure-europe (26)
- # clojure-nl (2)
- # clojure-uk (13)
- # clojurescript (19)
- # code-reviews (3)
- # conjure (18)
- # core-async (4)
- # core-matrix (5)
- # cryogen (3)
- # datomic (27)
- # depstar (21)
- # emacs (2)
- # figwheel-main (9)
- # fulcro (18)
- # helix (7)
- # jobs (3)
- # jobs-discuss (15)
- # juxt (7)
- # kaocha (4)
- # lambdaisland (2)
- # leiningen (11)
- # luminus (1)
- # malli (6)
- # meander (9)
- # minimallist (4)
- # mount (3)
- # off-topic (3)
- # pathom (8)
- # pedestal (28)
- # rdf (13)
- # re-frame (7)
- # reagent (5)
- # shadow-cljs (3)
And also the console.
Naturally, it was CORS. Thanks 🙂
Hi everyone, new here and fairly new to re-frame. My question that has brought me here is “is there such a thing as too many subscriptions?”. I’m building up an app where one key within app-db has about 15 subkeys. Each of the 15 is involved in a different component. Am I better off with 1 subscription to the parent and extracting the subkeys, or am I better off registering the 15 as second level subscriptions? Or is there another option I’m not seeing? 1 subscription seems like I’d be re-rendering a load of components unnecessarily. 16 subscriptions feel like a lot of boilerplate (albeit succinct boilerplate - yay cljs!)
If those are really simple keys and you get all your subs values via simple get
, then performance-wise there should be no noticeable difference. Design-wise - depends on your overall approach to the development. Subs are like getters in this case.
the DOM is sloooooooooow. you can run a lot of cheap subs to save a single DOM call, let alone a re-render.
on the other hand, if say some 6 subs always update together, there's no real benefit to splitting them up vs. 1 sub.