;; A
(defn button [{:keys [on-click]}] [:button {:on-click on-click}])
(defn Card [] (let [id @(subscribe [:foo])] [button {:on-click #(dispatch [:click id])}]))
;; B
(defn button [{:keys [on-click]}] [:button {:on-click #(dispatch on-click)}])
(defn Card [] (let [id @(subscribe [:foo])] [button {:on-click [:click id]}]))

I can't imagine any material difference between A and B

@souenzzo ^^

@souenzzo @mikethompson the one thing I thought, but not too sure, is that A may try to render button more often

Since the anonymous fn would change every time, even if id hasn’t changed.

The different fn’s as props would never be =

in the case of B the vector would be = even when a new vector is made, so the props would still be = for Reagent rendering cycle

However, I’m not sure how big of an affect that should really be in such a tiny case

Neither would their be any difference between @(subscribe ...) and @id. Maybe if you were completely paranoid about performance, you might try:

(defn button 
   [*id] 
   [:button {:on-click #(dispatch [:on-click @*id])}])

(defn Card
   []
   (let [*id  (subscribe :foo)]     ;; subscription outside - we name cursors with a leading *
      (fn []                      ;; note the render function 
          [button *id]
           )))

Back in the day when we passed subscriptions around we would always name them with a leading *, so make it clear they were not values

But we stopped doing this approach because we found it confusing when we later came back to the code.

@mikethompson Wouldn't dereferencing a subscription inside an :on-click handler leak the subscription in case a user never clicks the button?

I think it will be okay. The subscription is "captured" by the act of rendering button. When button goes away, the subscription will be released

I’d think that it wasn’t reactive anymore if the :on-click never happens

Oh, right. Now I get what you are saying

Very true. Sorry, i missed that @p-himik

Thanks for confirming. 🙂

I wonder if @souenzzo saw a performance difference in some case or if it was just speculative

@mikerod I agree with your analysis about the function parameter never testing equal.

Was it re-frame docs that actually mentioned that as a potential perf issue? I can’t remember. However, I understand conceptually why it’s the case

Yeah, I wrote about it in "Eeek performance problems" https://github.com/Day8/re-frame/blob/master/docs/Performance-Problems.md

In normal everyday use it doesn't really matter at all. But if you have a LOT of one kind of component, then its the equivalent of a tight loop, and you might need to optimise. Maybe.

ah yeah, there it is

Yeah, I don’t tend to worry about it most of the time

Perhaps this is the moment when I plug re-frame-trace. X-Ray vision for your re-frame app. Well, it will be that eventually. Still a bit simple ... but surprisingly useful. A new version is about to drop.

Hmm- I'm reminded of some performance problems in a React table thingy I wrote a while ago.

Our CTO said "Isn't React supposed to be fast, and solve this?"

I almost sent him the perlisism 'When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.'

There's very little as fast as whacking data in place.

But try to get it right, in the lone run.

A bit OFF from re-frame: but I'm a CSS noob, at the moment, I'm <link src="bootstrap.css"> on my index.html and writing some :button.btn. What are the possible paths to a "real" CSS architecture? #garden is the way? Need something else then garden to make everything works on a re-frame project? Examples?