Fork me on GitHub
#reagent
<
2020-05-13
>
p-himik07:05:59

@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-himik07:05:07

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

👍 4
Wilson Velez14:05:18

@U2FRKM4TW thanks for you answer, final question, what do you recommend in this case?

p-himik15:05:05

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

Wilson Velez15:05:00

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

lilactown15:05:34

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-himik15:05:20

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

p-himik15:05:00

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

lilactown15:05:28

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

p-himik15:05:50

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.

lilactown15:05:14

cool, checking my understand

Wilson Velez15:05:02

thanks for the explanation, it’s more clear now