This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (2)
- # beginners (20)
- # boot (13)
- # cider (36)
- # cljs-dev (11)
- # clojure (31)
- # clojure-berlin (3)
- # clojure-czech (2)
- # clojure-dev (2)
- # clojure-japan (9)
- # clojure-russia (16)
- # clojurebridge (3)
- # clojurescript (182)
- # cursive (8)
- # datascript (2)
- # datomic (35)
- # editors (33)
- # hoplon (18)
- # ldnclj (11)
- # off-topic (6)
- # re-frame (3)
- # reagent (39)
I posted the following gist yesterday on #C073DKH9P https://gist.github.com/jhchabran/e09883c3bc1b703a224d Besides point 1 which has nothing to with Reagent , do you guys think it’s correct enough to make a PR to reagent-recipes to update the gmap example ? (According ofc that I replace the subscribe call feeding coordinates with some traditional atom)
@escherize: I’ve removed the atom holding the gmap, it was necessary only because I didn’t place the
run! in the right scope, instead of putting it inside
@jhchabran: btw just curious, where does re-frame talk about not using reactions in views?
@antishok: Mike says it there : https://github.com/Day8/re-frame/issues/102 > reaction should not be used in views (as you have done above). Should only be done in subscriptions. Best to have a look at the examples.
well i think he means not to use the reaction in the render function itself, it's ok to have reactions in the outer setup function (of a "form-2 or 3" component)
and yes it's best if those reactions are subscriptions or based on subscriptions, instead of raw access to app-db
@jhchabran: that Gist looks wrong on a number of levels -- that use of
run! look very wrong. I'm dunno about the google maps interface, and i don't have much time ... but a sketch ....
First create a wrapper which does the subscription and passes it as props to a child:
At this point you can create a
(defn wrapper  (let [pos (subscribe [:current-position])] [google-map @pos]))
google-mapcomponent which wisely uses its one parameter. You can add lifecycle methods like component-did-update (which will get called when the props change), etc
@mikethompson: thanks for your feedback google map interface isn’t really important, it was mostly how to call some js functions updating it when my data changes
Hopefully that nudge about using a wrapper, sending in props, and Nils' code will help you along
run!) should only be used in subscription handlers. Never in a view.
Is available via: https://github.com/Day8/re-frame/wiki/More-advanced-Reagent-techniques
Has to be a Form-2 function
(defn wrapper  (let [pos (subscribe [:current-position])] (fn  ;; <--- return the renderer [google-map @pos])))
No, previously the subscription would have been destroyed and recreated on every render.
But, using Form2, the subscription is created once, in setup part, and the value then flows through to the render function, which might be called many, many times.
@antishok: as it is, it is a memory leak. That
run! will never get cleaned up. And that means the subscription
pos (which it uses) will never be cleaned up. Which means as you create more of these map components, you'll get more and more active (but unused) subscriptions. So every time app-db changes, there'll be all this unnecessary processing in the unused, but still-there subscriptions, etc.
You may be able to get away with this leak in an app that has only one map component. But it isn't a pattern that will work more generally.
@nblumoe: thanks for that blog post, I've pointed quite a few people to it over the time.
@nblumoe: in that post, you talk about having problems with vectors of params. I suspect you ran into https://github.com/Day8/re-frame/wiki/Using-%5B%5D-instead-of-%28%29#appendix-2 Although that is a guess, and based on not much information.