Fork me on GitHub

@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.


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?


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.


@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.


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”)


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


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


Thanks! Mine as well 🙂