Fork me on GitHub
#reagent
<
2018-05-31
>
mikethompson02:05:27

@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}) ....]

pesterhazy07:05:44

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

pesterhazy07:05:10

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

valtteri09:05:44

@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

đź‘Ť 4
valtteri09:05:28

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

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

kurt-o-sys11:05:41

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])])
does work, but adds an additional :div, although this shouldn't be necessary. However, doing this:
(for [c components]
     ^{:key (str c)} c)])
(obviously) doesn't add a key to the components c.

kurt-o-sys11:05:09

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

troglotit11:05:19

You could try fragments: [:<> c]

mikerod13:05:10

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

pesterhazy13:05:37

@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

kurt-o-sys13:05:48

@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.

pesterhazy13:05:04

usually the extra div shouldn't hurt

pesterhazy13:05:45

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

pesterhazy13:05:05

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

mikerod13:05:12

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

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

kurt-o-sys13:05:49

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

mikerod13:05:56

or if those components are coming more dynamically, then

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

mikerod13:05:29

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

mikerod13:05:37

into doesn’t even require keys at all

kurt-o-sys13:05:37

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)

mikerod13:05:12

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

mikerod13:05:28

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

kurt-o-sys13:05:33

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

mikerod13:05:44

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

mikerod13:05:50

I mean it isn’t useful

mikerod13:05:01

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

kurt-o-sys13:05:20

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

mikerod13:05:37

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

mikerod13:05:45

That is, if you were doing big enough intos

kurt-o-sys13:05:06

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

mikerod13:05:37

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

kurt-o-sys13:05:43

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

kurt-o-sys13:05:52

oh, ok, get it...

mikerod13:05:23

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

kurt-o-sys13:05:38

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)?

mikerod13:05:03

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)

mikerod13:05:15

I don’t know that key does anything with into

mikerod13:05:34

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

kurt-o-sys13:05:43

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

mikerod13:05:57

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

kurt-o-sys13:05:15

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.

đź‘Ť 4
mikerod13:05:37

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

mikerod13:05:08

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

kurt-o-sys14:05:07

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

âś… 4
kwladyka20:05:56

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 🙂