@mikethompson: thanks! will do

@mikethompson: argh, what a mess! can’t get this thing to work lol throws an “Error rendering component” in my top component, in the first subscription, as far as I can see

here’s the sanity hint

A sanity hint for incoming uncaught error: var STARratom_context_STAR_56784 = reagent.ratom.STARratom_context_STAR_; reagent.ratom.STARratom_context_STAR_ = obj; try{return f <<< :radioactive_sign: NULL :radioactive_sign: <<< .call(null);

but hey, not everything is lost: I have radioactive signs in my console now 😆

the thing is that my app is not exactly organised in the recommended way, because I've split my views across a few namespaces. They all only contain views, so I guess if I put the trace macros on all of them it should be fine?

Well, there are also a few defs (as in, not defns), do these mess the tracer? Do I need to take these out?

@mikethompson: thanks! I was putting a println inside the component and that's how I was seeing it "re-render", but you're saying even if that println fires, that doesn't mean an actual Hiccup/React/DOM render is happening?

Also, I'm here because Daniel Higginbotham, author of Clojure for the Brave and True, endorsed re-frame by using it for a couple of sites including http://clojurework.com: https://twitter.com/nonrecursive/status/705207468494868480 👏

And it's awesome

Hello, is there any performance of other difference between simple and dynamic subscription but working principle? It seems that dynamic subscriptions cover larger amount of scenarios so making all subscriptions dynamic looks reasonable to me.

@fasiha: the println tells you if the reagent render was called, producing new hiccup. And then Reagent has to turn that hiccup into VDOM, and then React has to check this VDOM with its current retained-VDOM to see what is different and changes must be made to the DOM. So it is definitely better that a renderer does not run UNLESS there are changes.