@kwladyka you'll likely need to turn the props into js (I don't know anything of this React component, so this advice is generic in nature):

[grid   (clj->js  {:container true}) ....]

not necessarily - reagent does some clj->js'ing by itself

but it's true that sometimes with deep data structures you need clj->js

@kwladyka what you probably want is something like

(def grid (r/adapt-react-class Grid))

(defn grid-container [props & children]
  (let [props (merge {:container true} props)]
    (into [grid props] children)))

;; Now you can use grid-container similarly as 'grid'
;; but :container will be true by default

& children and (into [grid props] children) is for making it work when your grid-container has children like this:

[grid-container {...}
  [grid {...}]
  [grid {...}]]

If I pass in an array of components to another component, and I loop over them, I seem to have issues with unique :key:

(for [c components]
     ^{:key (str c)} [:div c])])

(for [c components]
     ^{:key (str c)} c)])

Is adding an extra :div the only/best option?

You could try fragments: [:<> c]

@kurt-o-sys what are the components? do you have an example of how they are “passed in” to this component with the for?

@kurt-o-sys I recommend making things explicit, i.e. using (into [:div] (map ...)) for Reagent hiccup and using the :key prop rather than meta data: https://presumably.de/reagent-mysteries-part-1-vectors-and-sequences.html

@troglotit gives an error: Uncaught Error: Assert failed: Invalid tag: '' @mikerod sure, it's just passing a vector of reagent components to the function: [parent [[comp1 {...}] [comp2 {...}]] @pesterhazy well, still needs that extra :div. But if I understand well, that into syntax with a :key prop is better for some reason? OK, Will change it, and I'll just add that :div, since that seems to be the way to go. thx.

usually the extra div shouldn't hurt

to me it's easier to grok if the invariant holds that every component (ultimately) resolves to a single DOM element

re: meta-data, it's just easier not to mess up the :key prop

ok.

@kurt-o-sys that seems odd to me to call it that way, I’d think:

[parent [comp1 {...}] [comp2 {...}]]

why? - I just inject a list of sub-components?

or if those components are coming more dynamically, then

[parent (for [c comps] [c {:key <something>}])]

@pesterhazy The suggestion to use into is different than a for (or any nested list) I believe

into doesn’t even require keys at all

Right, so that's the same thing, right? - I have a vector of components to pass (dynamically, since I don't know how much there will be)

I thought with into you are just explicitly adding children to the component in a non-collection way so there is no identification-by-key semantics in play

@kurt-o-sys yes, but I’d add the key at that level

oh, cool, with that into, no need for that 'key' prop...

but with into there is no key prop needed, I don’t think it can even be used

I mean it isn’t useful

You probably can put it (aka didn’t mean it will fail)

🙂 - I can just omit the :key prop. Makes more sense to me.

However, I think you could take a performance hit with into vs something like for with keys for the same reason that key’s are useful to the React diff’ing algorithm

That is, if you were doing big enough intos

right. So, into may(!?) have a performance hit...

In larger collection cases, React uses the key prop to pinpoint which components correspond to the “same component” to diff

so, what would be the order of magnitude of 'enough' ? 🙂

oh, ok, get it...

so if you had like a N size collection (into [:div] n-components) and then you add 1 to the front of n-components in the next render, I think all will have to re-render

So, using into and adding a key prop to components may work just as well as doing a for-loop (and adding the :key metadata)?

if you used keys appropriately, you could make React aware that only a new component was added, the rest are still the same components (which may still be = and not need to re-render)

cool.

I don’t know that key does anything with into

If you aren’t dealing with a large collection that may keep changing though, into vs for style probably doesn’t matter performance wise

ok... so I may stick to the original for and just add key-metadata properly.

thx!

yeah, I can’t decided immediately for you without context. If you can use the for with key and get it working, I’d probably lean towards that

exactly, it's more readable, and I can't see much advantages for into, except no need for that key property... but if I just add ^{:key (str c)} metadata, it works fine.

I’ve used into before when I have only a small list of children components and I don’t expect there to be a change in its size over time - it is fixed and each position in the collection is the “identity” of the child component anyways

because in those cases, it isn’t useful to have to come up with a key anyways

makes sense... I won't care too much about it now, it works fine, and I get it. Nice, thx again.

wow thank you guys for help. @lee.justin.m @mikethompson @pesterhazy @valtteri 🍺 🍺 🍺 🍺 I was thinking there is some “reagent way” to make this component, but your solution will probably work 🙂