3 ms·

I don't think it's quite the same, is it? In the Reagent example, you declare the atom outside of the component function, and that atom would end up shared if

by rpeden 8y ago

I don't think it's quite the same, is it? In the Reagent example, you declare the atom outside of the component function, and that atom would end up shared if there were multiple instances of the counting component. In the react example, each instance of the component would have its own separate state. Reagent will let you put the atom inside the component, too, so you can do something very similar to the React example. Just wanted to point out that the two examples you've got now do different things.

emmanueloga_ 8y ago
hmmm yeah here's a better example: (defn timer-component [] (let [seconds-elapsed (r/atom 0)] (fn [] (js/setTimeout #(swap! seconds-elapsed inc) 1000) [:div "Seconds Elapsed: " @seconds-elapsed]))) Now the atom is defined inside the component function, and is captured by lexical scope in the returned function. Any timer-components on page will have their own `seconds-elapsed` state.
- wildermuthn 8y ago
  This was such a common pattern that reagent created a macro for it. But I like the macro-less code, in that it becomes very clear what is happening. A good macro reduces complexity by making code concisely simple. A bad macro hides complexity by making code easy to write. Frameworks like React succeed when they are built like a good macro. In this case, React is both hiding complexity (component lifecycles) while adding unnecessary complexity (a lInter that will inevitably fail). It’s odd to see React make this move, but not surprising considering that it now has a larger use-base then ever before.
  - emmanueloga_ 8y ago
    Are you maybe talking about with-let? I'm fairly new to reagent and not really familiar with any of its macros As it turns, there are only 5 macros, and only a some of those seem to be part of the public API, which is how I found about `with-let` :-) https://github.com/reagent-project/reagent/search?q=defmacro&unscoped_q=defmacro https://github.com/reagent-project/reagent/search?q=defmacro...

by rpeden 8y ago

emmanueloga_ 8y ago

hmmm yeah here's a better example: (defn timer-component [] (let [seconds-elapsed (r/atom 0)] (fn [] (js/setTimeout #(swap! seconds-elapsed inc) 1000) [:div "Seconds Elapsed: " @seconds-elapsed]))) Now the atom is defined inside the component function, and is captured by lexical scope in the returned function. Any timer-components on page will have their own `seconds-elapsed` state.

wildermuthn 8y ago
This was such a common pattern that reagent created a macro for it. But I like the macro-less code, in that it becomes very clear what is happening. A good macro reduces complexity by making code concisely simple. A bad macro hides complexity by making code easy to write. Frameworks like React succeed when they are built like a good macro. In this case, React is both hiding complexity (component lifecycles) while adding unnecessary complexity (a lInter that will inevitably fail). It’s odd to see React make this move, but not surprising considering that it now has a larger use-base then ever before.
- emmanueloga_ 8y ago
  Are you maybe talking about with-let? I'm fairly new to reagent and not really familiar with any of its macros As it turns, there are only 5 macros, and only a some of those seem to be part of the public API, which is how I found about `with-let` :-) https://github.com/reagent-project/reagent/search?q=defmacro&unscoped_q=defmacro https://github.com/reagent-project/reagent/search?q=defmacro...