This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (2)
- # beginners (10)
- # boot (253)
- # cider (11)
- # cljs-dev (26)
- # cljsjs (21)
- # cljsrn (7)
- # clojure (87)
- # clojure-berlin (13)
- # clojure-dusseldorf (5)
- # clojure-greece (7)
- # clojure-poland (11)
- # clojure-russia (189)
- # clojure-spec (31)
- # clojure-uk (86)
- # clojurescript (89)
- # cursive (15)
- # datavis (2)
- # datomic (57)
- # devcards (3)
- # dirac (92)
- # editors-rus (3)
- # emacs (4)
- # events (1)
- # funcool (30)
- # hoplon (3)
- # jobs-rus (6)
- # leiningen (1)
- # luminus (12)
- # mount (25)
- # off-topic (5)
- # om (43)
- # onyx (41)
- # perun (1)
- # proton (2)
- # protorepl (7)
- # re-frame (17)
- # reagent (34)
- # ring (13)
- # specter (1)
- # spirituality-ethics (1)
Hey everybody 🙂 I just wanted to say thanks for re-frame. We now have 14k LOC of (front-end) clojurescript, all supported by re-frame and we are really happy with it!
I think this channel is a better place to ask than #C03S1L9DN :) are there any downsides of re-frame subscriptions like
(register-sub :get (fn [db [_ key]] (reaction (get @db key))))
@si14: the main benefit, for me at least, of subscriptions is that they neatly decouple the thing your subscribing to from the app-state. Using a subscription like the one above means you lose that benefit.. which is fine if you know the layout of your app-db isn’t going to change, but not something I’d be willing to sacrifice.
A common refactoring I’ve seen as my app-db has evolved has been switching from lists to maps. But because the subscription doesn’t care about the path or collection type, the changes I have to make are in most cases very small
@lsnape: thanks! The main reason why I feel the need for subscriptions like that is an abundance of trivial subscriptions in the code. It can be the case that I'm doing something wrong, of course
I know what you mean. Sometimes it can feel awfully repetitive writing specific cases where all you’re doing is a
get. Something to be aware of though
I wrote a simple function to automatically create subscriptions for certain keys in my db. Makes the base case easy, and you can always replace them with a different definition later.
@si14 It kinda depends on your app as to how much of an abundance of these simple getters you see.
Problems with a generic getter:
1. The views now know about the structure of app-db. They hold path information. The entire reason for subscriptions is so that components ask for data with no knowledge of where it comes from.
2. Shortly, when 0.8.0 comes out, you'll be wanting to use
reg-sub which provides effecient de-duplication of the signal graph (where that matters).
The way you have written you generic getter subscription, it will fire every time db changes, for any reason whatsoever.
Best tutorial on the subject, currently https://github.com/Day8/re-frame/blob/develop/examples/todomvc/src/todomvc/subs.cljs
@mikethompson: yeah, I'm looking forward for 0.8.0 release! I will definitely need to reeducate myself about fetching data into the app, though.
@si14: at one point we had partial subscriptions (analogous to partial functions) which we used to subscribe to a portion of the app-db tree and which took a key for their final parameter
Howdy all. I’m starting to play around with re-frame and so far it’s pretty fun to work with
Sometimes I want to grab an arbitrary value from the db and I end up doing something like this
(let [something (subscribe [:something])] @something)
Will I create a memory leak if I create subscriptions willy-nilly whenever I need to access app-db?