Fork me on GitHub
#re-frame
<
2020-02-06
>
martinklepsch13:02:29

I remember reading some stuff about why get-in style subscriptions aren’t what you usually want — can anyone point me to where that is written down?

martinklepsch14:02:21

Thank you very much Eugene!

👍 4
manutter5113:02:40

TLDR is subscriptions are cached, if you subscribe to (get-in db [:a :b :c]) your component will re-render every time :a changes (or maybe it’s every time db changes). Done properly, it will re-render only when :c changes.

manutter5113:02:39

Since :a changes whenever anything under :as changes, that’s a lot of extra and unnecessary re-renders.

p-himik13:02:03

> if you subscribe to (get-in db [:a :b :c]) your component will re-render every time :a changes That's not true, I think. The sub will be re-run, yes. But the component will be re-rendered iff (get-in db [:a :b :c]) value is changed.

manutter5113:02:17

You know what, I think you’re right, now that I think about it. That’s a “fact” I got in my head a long time ago and I’ve never really challenged it, but you’re right, there’s no way for re-frame to track the state at every step in the “get-in” path. I withdraw my comment.

manutter5113:02:53

People should ignore me and just read the “A Final FAQ” section of the link you posted in your thread.

isak15:02:51

If you use reg-sub-raw with a reaction that dereferences a cursor, the subscription will not be re-run unless the cursor path changes