Fork me on GitHub

@johanatan Can you give a bit more info ? Do you mean you want to do this:

(defn my-component
   ^{:key "blah"}(some-other))


If so, remember that ^{:key "blah"} will only work on a literal


So this works:

^{:key "blah"}[]
But this does not:
^{:key "blah"}(identity [])


For the second one, you have to instead use with-meta


@mikethompson No, I literally wanted to do it on a (fn [] ...)


i.e., a Form-2 component


I also did try with-meta when I was messing around with this but it didn't work.


I ended up converting my Form-2 components into Form-1 components


As I realized that I didn't really need to close over any local state anyway


And it could be recomputed with impunity


So... imagine this:

(defn timer-component []
  (let [seconds-elapsed (reagent/atom 0)]     ;; setup, and local state
    ^{:key "want to put key here"}
    (fn []        ;; inner, render function is returned
      (js/setTimeout #(swap! seconds-elapsed inc) 1000)
      [:div "Seconds Elapsed: " @seconds-elapsed])))


I also tried:

(defn timer-component []
  (let [seconds-elapsed (reagent/atom 0)]     ;; setup, and local state
      (fn []        ;; inner, render function is returned
        (js/setTimeout #(swap! seconds-elapsed inc) 1000)
        [:div "Seconds Elapsed: " @seconds-elapsed])
      {:key "key here"})))    
and that did not result in a 'key' being shown in the React dev tools in Chrome


@johanatan think about it this way. Reagent allows you to return a hiccup formatted data structure (nested vectors and maps). And parts of that data structure can have meta data which indicates keys.


You seem to be trying to do something else 🙂


It is like you are trying to add key meta data to the functions which return the hiccup, rather than the hiccup itself


No, the fn I tried to add it to is a return value. It is not directly invoked by any of my code but rather by the runtime/framework code.


Reagent also allows you to "return this type of fn-defined component". It is known as a Form-2 component (per the Reagent docs).


You can easily verify for yourself what I'm telling you: construct a page with at least one Form-2 component and notice that you see a "ReagentXX" element in the Chrome React dev tools element hierarchy corresponding to each Form-2 component on your page. Notice also that upon each render these Form-2 components' element types get the XX bumped. Notice also how that is a killer on performance as React considers unique element types to be unique in substance as well as type (and thus not identical and thus not eligible for its perf-enhancing goodness).


I would like to change that (hence the desire to add :key metadata to the closure).


@johanatan I assure you I understand Form-2 components reasonably well. I named them when I wrote the documentation 🙂 I'm confused by what you are saying. I fired up the todomvc example supplied with re-frame. It has a component called task-list which is Form-2. I look at it in Chrome React devtools and I don't see a ReagentXX element, as you suggest I might. . And I see no key on it. So I'm stuck as to how to interpret your question.


@mikethompson the fact that you see no key on it is expected and what i would like to change so not sure why you mentioned that. i'm also not sure why you are having trouble understanding my words as I think I've been very clear and precise. what part of my question do you not understand? Perhaps one more detail that is different between our codes: can you try having the timer-component above as a child in a v-box like so: [re-com/v-box :children [(timer-component)]. Then I think you should see the "reagentXX" as expected in the React devtools hierarchy.


Are you also saying that under no circumstance ever have you seen the "reagentXX" components appear in your React devtools hierarchy? I would imagine that at least one of the Reagent devs would know the source of/trigger for the creation of this [problematic] type of component but if none of them chime in anytime soon, then I will dig into the source code and see for myself.


@johanatan When you use a Form2 component, you absolutely not should be calling it in the hiccup like this [(timer-component)] you should instead be [timer-component]


@mikethompson yes, I understand/know that but when this Form-2 component has another Form-2 component as a child, then the child does not get updated properly when both are specified like [component]. changing the outer one to [(component)] fixes my "does not update when input cursors" change issue on the child hence why I did that.


When you use the [(timer-component)] you will indeed be recreating the component each time.


@johanatan > when this Form-2 component has another Form-2 component as a child, then the child does not get updated properly when both are specified like [component] This should work fine. Done it a 1000 times.


Hmm, then there must be other confounding factors


I think you need to great a minimal repo showing an example of the problem you are seeing. Then we can probably help more.


Ok, I'll try that. Thanks


Do you know if "trace react updates" can be trusted? I'm sort of doubting some of its output and wonder if this: is a factor?


i.e., my code per your "when do components update" should not be updating many of its components as much as the "trace react updates" from devtools is indicating. Not sure if those are really being updated or if I am suffering from the fact that react-devtools is not honoring shouldComponentUpdate return values (which reagent may be giving it).


If you are unsure, put a println in the render part of any component.


(defn my-component 
    ....                        ;;  don't put a println out here because this isn't the renderer
    (fn [] 
       (println  "rendering my-component")
       [:div "hello"]))


ahh, good call. thx!


Hmm, well I guess part of the confusion here is that I know certain render functions (which are ancestors of the input being typed into) must be running (as the input being typed into is on a leaf node)


But all of the elements returned to React higher up in the tree should be identical from a DOM perspective to the previous iteration


(defn my-component 
    (println "my component setup - should only be called once")
    (fn [] 
       (println  "rendering my-component")
       [:div "hello"]))


And IIUC "trace react updates" should not be highlighting structurally identical DOM elements from one render to the next


e.g., one of the elements in question is a Material UI "toggle" element which should have identical inputs from the previous iteration


Yet "trace react updates" is highlighting it and many of its siblings/cousins on the way to the leaf input which is actually being typed into


[and which is the only thing actually changing on the page]


So I guess I'm really asking: does "trace react updates" actually highlight DOM elements that have changed? or elements which were generated by render functions which ran (but may or may not have actually changed)?


It seems empirically to me that it is the latter and that it probably isn't a big deal that many of these are re-drawing (as there isn't really any better/other way to structure this to prevent it).


Not sure about that extension ... i don't use it


Now wait. This is the reagent channel, not the re-frame channel. So you may not be using re-frame.


@mikethompson I actually am using re-frame. But I'm finding that reagent/cursor is typically all I need for event sources (rather than a full-blown subscription and handler).


So the renders in question are all tied to cursor rather than subscription and so I don't think that event-based debugging will help.