Fork me on GitHub
#reagent
<
2017-09-15
>
mikethompson00:09:32

@erwinrooijakkers app-db will be an input Signal to that reaction. Any change to an input Signal, will trigger a re-run of the reaction. So any change whatsoever to app-db will trigger a re-run.

erwinrooijakkers09:09:48

Okay thanks! So it will run on EVERY change to app-db? Not only a change to the result of the query on app-db?

erwinrooijakkers09:09:22

I did see that I have to use the reaction in a component, when I take the reaction as a parameter to a component the component is not updated on a change. E.g.,

(defn inner-component [reaction-state] (fn [reaction-state) <does not rerender on change to reaction-state>))
(defn wrapper-component [] (let [screen-state (reaction ...)] (fn [screen-state] [inner-component screen-state])))
The inner-component does not rerender on a change to screen-state.

reefersleep11:09:21

@erwinrooijakkers I think the brief explanation is thus: if you deref something inside a component, the component is only re-rendered once the resulting value from the deref returns something different from previous derefs.

reefersleep11:09:07

something here could mean both an r/atom, a r/reaction or a r/cursor (and maybe r/track, I don’t have a full overview of the many flavors of dereffable “reaction-likes”)

reefersleep11:09:26

And likewise, a reaction body will be run if the dereffable(s) it derefs result in new values - but it might be that the product of running the reaction body is the same value as before, meaning that the deref of the reaction does not cause a re-render

reefersleep11:09:05

This is my understanding, I hope that it is correct 😄

erwinrooijakkers11:09:34

Thanks! Mine as well 🙂