Fork me on GitHub

Given this example from the Reagent readme:

(defn timer-component []
  (let [seconds-elapsed (r/atom 0)]
    (fn []
      (js/setTimeout #(swap! seconds-elapsed inc) 1000)
       "Seconds Elapsed: " @seconds-elapsed])))
...doesn't that create a setTimeout that will be perpetually running? Perhaps they can even pile up after various rerenderings and cause a small memory leak. Would resorting to create-class the only alternative for implementing a component that knows how to clean up itself?


also callback in setTimeout is called only once (I think you interchanged it with setInterval).


ah yes, I had setInterval in mind


amazing! happy to check reagent is so well thought-out. Thanks ✌️


do you get the same level of re-rendering efficiency by passing a reagent atom to a component that you do by initializing it in the function itself? Does it matter, and what is the common practice? To create the state in the parent-most component and pass it down, or keep it outside of the component and access it like any namespaced def?


@theeternalpulse think there are different schools of thought. Personally, I prefer passing in the one app-state ratom as an argument to the component as opposed to referencing a global def directly. It makes testing easier (and helps me sleep at night 😂). As for initializing a ratom in a component itself, I lean on cursors of the one app-state ratom rather than making one-off local ratoms for the component. Helps visibility when using tools like re-frisk.


if you pass the ratom itself into components, that fact by itself won't affect rerendering


think about this way: this ratom itself (an object with a certain memory location) won't change


so from the rerendering standpoint it doesn't matter if you pass it in as an argument or use a global var


re-frame uses a global var, and I think there's nothing wrong with that


to add to what @gadfly361 said, passing in the ratom explicitly is a matter of style, perceived "code hygiene" and convenience


I think it's a bit annoying to pass it around to every single component that uses state

💯 8

I also don't care for testing UI code thoroughly so maybe I just have bad habits 🙂


yeah, that's a thing I hated in react


even with context, it's a mess, especially when people spread in properties so you really can't visually tell at certain levels what was passed in


I did like react's solution of centralizing that stuff


Re-frame's choice to remove passing app-db around is wonderfully convenient and you can still test the important bits, the handlers