Fork me on GitHub

Thanks, I'll take a look. Still seems like a problem where many people cobble together a just-enough solution and then move on. Enter/exit animations can be pretty painful!


does anyone have any links to repos of well-made small-to-medium size reagent apps? i'm looking to read some source code to get a better idea of idiomatic cljs and also project organization


it is a toy example still, but a bit larger than the “TODO list”


You may be looking for more real than that - I don’t know of anything better at the moment (I like to see things like that too)


If I have a component defined as such:

(defn my-widget
  [{:keys [a b c] :as props}]
  (init-some-stuff! props)
  (fn [{:keys [a b c]}]
    [:h1 (str a b c)]))


Do I really need to be repeating the function arguments again in the nested function?


In other words, what are the consequences of doing this:

(defn my-widget
  [{:keys [a b c] :as props}]
  (init-some-stuff! props)
  (fn []
    [:h1 (str a b c)]))


The outer function is only called once, and is meant for setup (as you indicate in your example. The inner function is the renderer, which will re-render when its input changes. Since you don't give the inner function any arguments, the component will render once with the arguments supplied to the outer function, but it will never re-render.

cjsauer20:11:20 then I do indeed have to write out the function arguments twice? Is reagent sort of swallowing the arity exception then? Is that what prevents a re-render?


I don't think arity exceptions exist in JS


@U5YHNV0EA oh duh....I'm too used to Java-land. Thank you for your help @U0J30HBRS, much appreciated.


@cjsauer there are a bunch of useful tutorials at the bottom of this page, under the heading "Reagent Tutorials".


Cool, much appreciated. I'll take a look.


The relationship between function arities that are defined and the arity passed to a component by Reagent is a bit magical and not obvious