A minimalistic ClojureScript interface to React.js
p-himik 2020-05-13T07:39:59.454500Z

@wvelezva @lilactown It's not just a matter o f taste. Notice the component has if in there. If you use a form-2 component where some subs are @-ed only in one of the branches, then you will have memory leaks.

p-himik 2020-05-13T07:42:07.454600Z

@sansaripour Making sure you see this to avoid repeating the whole message in #re-frame


@p-himik thanks for you answer, final question, what do you recommend in this case?

p-himik 2020-05-13T15:01:05.455Z

I just use @(subscribe [...]) everywhere. The only reason to not use @ right away is if you want to interact with the ratom itself.

p-himik 2020-05-13T15:02:27.455200Z

Check this out, along with the next section:


I also use @(subscribe [...]) everywhere, I just wanted to know if the other way has strong advantages

lilactown 2020-05-13T15:20:34.455700Z

hm. I’m not sure why you would have a memory leak problem doing:

(defn c []
  (let [x (rf/subscribe [:x])
        y (rf/subscribe [:y])]
    (fn []
      [:div (if @x @y "no y")])))
vs not wrapping in a fn

p-himik 2020-05-13T15:21:20.455900Z

If you do not deref a ratom, on-dispose will never be called when the view is unmounted.

p-himik 2020-05-13T15:22:00.456100Z

Same reason why you cannot use subscribe in a re-frame or a JS event handler.

lilactown 2020-05-13T15:22:28.456400Z

is that still true when using a form-1 and binding w/o derefing it in the let

p-himik 2020-05-13T15:23:50.456600Z

If you never @ a sub, then it is true. But it's OK with (if @(subscribe [...]) @(subscribe [...]) "no y") because the second subscribe will not be called unless the first one returns true.

lilactown 2020-05-13T15:24:14.456800Z

cool, checking my understand


thanks for the explanation, it’s more clear now

unbalanced 2020-05-13T20:33:08.457200Z


unbalanced 2020-05-13T20:33:18.457400Z

good to know